小项目的数据备份：把 3-2-1 原则做到便宜又够用

小项目最常见的死法不是流量把服务冲垮，而是数据丢了：一次误删、一块磁盘故障、一次手滑的迁移脚本，就能让几个月积累的用户数据归零。备份这件事，道理人人都懂，真正落地的却不多——原因往往不是不知道重要，而是觉得"正规方案太贵、太复杂，小项目不值得"。

其实 3-2-1 原则（3 份数据、2 种介质、1 份异地）完全可以低成本落地。下面是我给个人小项目定的做法，核心就一句话：备份要自动化、可恢复、可验证，缺了最后一条，前两条都等于没做。

一、3 份数据：生产之外再留两份，别只靠"一份导出"

很多人以为"我每周手动导一份 SQL 出来"就是备份了。但手动导出有三个问题：人会忘，导出时服务可能正在写数据导致不一致，导出的文件还常常就躺在同一台服务器上——服务器一挂，生产数据和备份一起没了。

我的做法是三份各司其职：第一份是生产库本身；第二份是自动化的每日快照或逻辑导出，由定时任务在凌晨低峰期跑，文件名带日期，保留最近 14 天；第三份是每周一次的完整备份，单独归档，保留 4 周。这样即使某一天的备份坏了，也还有前后几天的版本可以回退，而不是只有"最新一份，坏了就全没了"。

关键点是自动化：备份一旦依赖"记得做"，就注定会在最忙的那周断掉。定时任务加失败告警，比任何决心都可靠。

二、2 种介质：别把鸡蛋放在同一个磁盘、同一台机器上

"2 种介质"对小项目不用理解得很玄：核心是不要让备份和生产数据共享同一个故障点。生产库在云服务器的系统盘上，备份就不要只放在同一块盘里——至少要做到：本地一份（用于快速恢复，比如误删一张表，几分钟就能从本地快照捞回来），再加对象存储一份（用于机器整体故障时兜底）。

对象存储对小项目很友好：按量计费，几 GB 的数据一个月往往只有几毛到几块钱；开启版本控制后，即使备份文件被误覆盖，也能找回旧版本。本地备份负责"快"，对象存储负责"稳"，两者分工，恢复时先本地、再异地，基本能覆盖绝大多数场景。

三、1 份异地：异地不是异机房的专利，跨区域就行

"异地"听起来像大公司的专属词，其实对小项目来说，跨一个可用区、跨一个区域就已经够用了。同一机房断电、同一区域网络故障时，另一份备份还在，这就够了。不需要一开始就搞三地容灾，那是规模上去之后再考虑的事。

我现在的异地策略很简单：每日备份同步到对象存储的一个不同区域的桶里，每周完整备份再多存一份到另一个账号或另一个云厂商的免费额度里。成本几乎可以忽略，但一旦主区域出问题，恢复的底气完全不同。

四、最容易被跳过的一步：定期真的恢复一次

备份做完了，事情只完成了一半。真正决定备份有没有用的，是恢复演练——而且必须真的恢复，不能只看"备份文件生成成功"的日志。

我给自己定的节奏是：每月一次，把最近的一份备份恢复到一台临时环境里，跑通三件事：服务能不能起来、核心数据在不在、关键查询的结果对不对。第一次演练往往就能发现问题：备份脚本漏了一张表、导出时字符集不对、恢复后配置指向了生产库……这些问题在演练时发现是"修一下"，在真实故障时发现就是"事故"。

演练不需要很正式，半小时就够：起一个临时容器，导入备份，跑几个冒烟测试，确认无误后销毁。把演练日期记下来，下个月同一时间再来一次。

五、备份策略也要"够用就好"

备份保留期不是越长越好：无限保留只会让存储账单悄悄变大，最后没人敢删、也没人敢动。我的保留策略是分层：每日备份留 14 天，每周备份留 4 周，每月备份留 3 个月，超过的自动清理。既保证了"昨天误删能找回、上个月的数据还能追溯"，又不会让存储成本失控。

另外，备份里如果有用户隐私数据，加密是必须的：传输加密、存储加密、密钥和备份分开存放。备份文件本身也是数据泄露的入口，丢了一份未加密的备份，和丢了生产库没有本质区别。

结语

小项目的备份不需要一步到位的大方案：自动化每日备份、本地加对象存储两份、跨区域再存一份、每月真的恢复一次、分层保留自动清理——这套组合成本极低，周末一个下午就能搭完。它买到的不是"永远不出事"，而是"出事时有底气"：数据丢了能找回，服务挂了能重建，用户还在，项目就还在。

备份的价值，永远是在你需要它的那一天才显现。别等到那一天才发现，备份只是个没验证过的假设。