代码和数据库备份，别等丢了才做
2025 年 9 月 20 日那天，我发现代码和数据库怎么备份才不丢数据，自己根本没答案。我翻小游戏账本时想起，那款后来累计做到 ¥5700 的简笔画画板还没上线，先上的是另一款，而上线几天就废了。
废掉本身不心疼，我当天的第一反应是去确认代码还在不在，因为我答不上来「昨晚的库在哪」。
一、我踩过最贵的一课：代码和数据库怎么备份，我原先全靠脑子
那段时间我的「备份方案」是：代码在本地一台机器上，写完顺手推到远程仓库；数据库的表结构在代码里，数据本身只有线上那一份。
这不算方案，这是把赌注押在机器不坏上。而且我很清楚为什么当时没做——因为备份没有反馈。
不做备份，今天也不会出事；做了备份，今天也看不出差别。没有反馈的事，人就会一直往后拖。
真正让我改的是算清了一笔账：重写一遍那款小游戏要花的力气，和我现在花在备份上的时间，完全不成比例。备份不是技术问题，是把「概率小但代价不可逆」的事提前买断。代码和数据库怎么备份才不丢数据，本质上是道判断题，不是技术题。
我现在的做法很土：备份脚本不进我的日常待办，而是挂在已有的自动化任务里，跑完只留一行结果。不占注意力的备份，才能一直跑下去。
二、代码和数据库怎么备份才不丢数据，第二件事是别只放服务器上
现象是：线上有数据，本地只有建表语句，删库或者磁盘坏掉就等于归零。原因不在技术难，在于「反正就我自己用」这种心态。
我的后台服务跑在一台云服务器上，数据落在服务进程同级的目录里，平时根本不会想起它。
怎么避：这条线上有数据，就必须有一条自动的、我不参与也会跑的导出。具体做法按数据库类型不同，但判断标准只有一条——如果我现在把服务器整个删掉，昨天的数据能不能在新机器上恢复出来。答不上来就等于没备份。
还有一个细节：导出的时候尽量让数据处于一致状态，别在写入正忙的时候硬拷文件。这跟「有没有备份」是两件事，但它决定了备份能不能用。
三、备份文件也会丢，这才是最容易忽略的一层
我一开始以为导出了就完事，后来意识到一个更尴尬的问题：导出文件和数据库常常在同一块盘上，甚至在同一台服务器上。
那不是备份，那是复制。同一份故障域里的两份副本，等于一份。
后来我改成两件事分开看：一份留在机器上，恢复快；一份定期挪到机器之外，恢复慢但能兜底。挪出去的频率可以低于本地，但一定要有，而且要确认它真的能拿回来——没验证过的备份，不算备份。
挪出去的那一份还有个隐性好处：它会逼你想清楚「哪些数据是真的不能丢」。
四、光备份不够，还得能恢复
这一步我拖了很久才补上。
备份是「产出」，恢复是「消费」，前者每天自动跑，后者几乎从不执行，所以坏掉也发现不了。我会定期做一次演练：在一台干净的环境里，把最近一次备份还原出来，看服务能不能正常起来。
恢复演练的意义不是恢复，是让你在真的需要时不用现场学。
五、止损清单：出事那一刻按顺序做
真出事的时候人是慌的，所以我给自己写了一张固定顺序的清单。
第一件是停止写入，别再让新数据覆盖掉可能还能救的部分；第二件是确认最近一次可用备份的时间点，把损失范围先框出来。第三件是先恢复再优化，不要在数据还没回来的时候去查根因；第四件才是复盘。
这份清单我写在系统里，不写在脑子里。慌乱时唯一能依靠的是流程，不是记性。
也就从那天起，代码和数据库怎么备份才不丢数据，对我从一道选择题变成了一条固定动作。
常见问题
Q：个人项目代码和数据库怎么备份才不丢数据？
A：代码进远程仓库，数据库做自动导出，并且至少留一份在服务器之外的存储上。三件事都做到，才叫备份，缺一件都只是自我安慰。
Q：备份多久做一次比较合适？
A：按你能接受丢多少数据来定，而不是按习惯来定。如果你觉得丢掉一天的数据可以接受，那就每天一次；接受不了，就提高频率。
Q：备份文件要不要加密？
A：建议加密，尤其是放到第三方存储上的那份。判断标准是：这份文件如果被别人拿到，里面有没有你不想外泄的东西。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」