给线上小服务做备份，我最后只留了三样东西

我线上跑着一个小服务，访问量不大，但它是真的在对外提供服务：有人在用，有数据在沉淀。以前我做备份的思路很简单，就是把整台云主机能打的包都打一遍，觉得东西越多越保险。直到有一次磁盘出问题要恢复，我才发现自己守着一堆备份文件，却不知道先恢复哪一个、恢复完怎么确认服务是不是真的好了。那次之后，我把备份的思路整个改了：不再追求备得多，而是想清楚到底要留下什么。最后，我只留了三样东西。

第一样：再也生不出来的东西

先问自己一个问题：如果这台机器现在没了，哪些东西是再也拿不回来的？我的答案只有两类：数据库里的数据，和用户上传的文件。代码可以从代码仓库重新拉下来，依赖可以重新安装，系统环境可以重新搭建，这些都不是不可替代的。但用户已经提交的数据、上传的图片和附件，一旦丢了就真的没了。

所以我的备份清单第一条就只写这两样：每天定时导出数据库，做一次全量备份；用户上传的目录单独同步一份。日志、缓存、临时文件、编译产物，一律不进备份。这样做的好处很直接：备份变小了，恢复的时候也不用在一堆文件里挑挑拣拣。

第二样：让服务长成现在这个样子的配置

光有数据还不够。同样一份数据库，配上不同的配置，跑起来的可能就是另一个服务。所以第二样要留下的，是配置：docker-compose 文件、Nginx 配置、systemd 服务文件、定时任务的列表，还有一份环境变量清单。

这里有个细节我吃过亏：环境变量清单只记变量名和来源，不记明文密码和密钥。真正的密钥放在另外的安全地方，恢复时再按清单逐项填进去。清单上还要记域名解析指向哪里、证书什么时候到期、对象存储用的是哪个桶。这些看起来都是小事，可恢复那天缺了任何一个，服务都起不来。每次改了配置，我就顺手更新这份清单，改配置和更新清单变成同一个动作。

第三样：一页纸的恢复清单

前面两样是“留什么”，第三样是“怎么恢复”。我写了一页纸的恢复清单，按顺序写清楚：先开一台新机器，再装运行环境，然后恢复数据库，放回配置文件，启动服务，最后跑三条检查命令。

写清单的时候，我假装是三个月后的自己在照着做：每一步写具体命令，不写“按需配置”这种含糊话；每一步后面写怎么确认这一步成功了，比如数据库恢复完要查一下最新一条记录的时间，服务启动后要实际调一次接口、登一次账号。清单最下面还有一行字：恢复完成的标准不是服务启动了，而是用户能正常登录、能正常提交数据。

备份放哪，多久验一次

三样东西我放两处：一份在云主机本地，方便随手取用；一份同步到对象存储，机器出问题也不受影响。保留策略也很简单：每天一份，保留最近七天，再留一份每月初的。超过的就删掉，不囤。

多久验一次恢复，我定的是每月一次。验的方法不是打开备份文件看一眼，而是真的在另一台测试机上，按那一页纸的清单从头恢复一遍，跑通登录和提交这两件事。第一次演练我就发现清单里少写了一个端口放行的步骤，平时根本发现不了。演练花的时间，就是真正出问题时能省下的时间。

现在再有人问我备份怎么做，我的答案就是这三样：无法再生的数据、让服务成形的配置、一页能照着做的恢复清单。东西不多，但每一样都知道为什么留、放在哪、什么时候用。备份的目的从来不是把文件存下来，而是出问题那天，能按部就班地把服务带回来。