备份做完了不算完：小服务器的 3-2-1 备份与恢复演练

很多小服务器的备份都是“搭的时候认真配过一次，之后再也没看过”。定时任务一直在跑，备份文件一直在攒，看起来万无一失。真到磁盘坏了、误删了、被入侵了需要恢复的那天，才发现备份文件是三个月前的、恢复步骤没人记得、或者备份里根本没有最关键的那一份——备份这件事，怕的不是没做，而是做了却没验证。

下面这套做法不依赖什么重装备，个人维护的几台小服务器就能落地：先想清楚备什么，再按 3-2-1 放，最后定期把恢复真演练一遍。

一、备什么：数据、配置，还有容易漏的那几样

第一类是业务数据。数据库不要直接拷贝正在运行的数据目录，那样拷出来的文件很可能是不一致的——要用数据库自己的导出工具做逻辑备份，比如 PostgreSQL 用 pg_dump、MySQL 用 mysqldump，导出的是一份能重新导入的干净快照。应用产生的文件、用户上传的内容，同样要进备份清单。

第二类是配置，丢了最耗时的一类。系统重装只要一小时，配置调回来可能要几天：反向代理的配置、防火墙规则、定时任务表、自定义的服务单元、证书和私钥、SSH 的授权密钥文件、应用的配置文件和环境变量，都要算进去。含密码、密钥的文件要加密存放，不能明文丢在备份里到处同步。

第三类是“装机清单”本身：系统装了哪些软件包、服务是怎么起来的、备份任务本身是怎么配的。这些不备份，真恢复时就得凭记忆重搭。把部署步骤写成文档或者脚本，和数据备份放在一起，恢复时才有路可走。

二、怎么备：全量与增量搭配，频率按“能丢多少”定

先定两个数：能丢多少数据、能停多久。前者决定备份频率——一天备一次，就意味着最坏情况下丢一天的数据；如果这个代价接受不了，就得提高频率。后者决定恢复要多快——恢复步骤越是现成，停机就越短。

常见搭配是每周一次全量、每天一次增量：全量恢复最简单，一份文件就能还原；增量省空间，但恢复时要按顺序叠加。保留策略可以用阶梯：最近 7 天每天留一份，最近 4 周每周留一份，最近 12 个月每月留一份。保留多份不只是防丢，更是防“坏数据被悄悄同步进备份”——发现文件被误删或者被加密时，还能往回找到一份干净的。

备份任务交给定时任务自动跑，但一定要配告警：任务失败、备份文件比预期小很多、连续几天没有新文件，都要能主动通知到人。一个没人盯的备份任务，静默失败几个月是常态，等发现时早就过了能补救的时间。

三、放哪里：3-2-1 原则，一份必须够不着

3-2-1 一句话讲完：重要数据留 3 份副本，放在 2 种不同介质上，其中 1 份在异地。落到小服务器上大概是这样：第一份在本机另一块盘或者另一个目录，防手滑误删，防不了整机故障；第二份在另一台机器上，比如同机房的备用机或者家里的存储设备，防单机故障；第三份在异地，同步到另一台异地服务器或者对象存储，防机房、火灾这种整站级别的事故。

还有一条硬规矩：备份的写入权限要单向。线上机器往备份端写可以，反过来备份端不能反向改线上机器；更进一步，定期留一份离线的——比如每周把关键数据拷到一块移动硬盘上，拷完拔下来收好。离线介质不联网、不挂载，勒索软件和误删都够不到它，是最后一道防线。

四、没演练过的恢复，等于没有备份

备份文件躺在那里，不代表能恢复。文件损坏、密码失传、版本对不上、证书私钥没备份过、恢复步骤没人会——每一种都得在真出事前发现。所以恢复演练要定期做，做法不复杂：

第一步，选个低峰期，找另一台机器，哪怕是台旧电脑或者临时开的云主机，把最近一份备份完整恢复一遍。第二步，恢复完真把服务拉起来：服务能启动、页面能打开、登录进得去，而不是只看一眼文件解压成功就收工。第三步，抽查数据：最新的记录在不在、对不对，恢复到三天前的数据是不是自己能接受的。第四步，记录耗时：从开始恢复到业务可用花了多久，这就是真实的停机时间，下次演练要比它更短。

演练十有八九会暴露问题，而每个暴露出来的问题，都是提前拆掉的雷。把演练中发现的缺口补进备份清单，备份策略才算真正闭环。

小结

小服务器的备份不用追求大而全，抓住四件事就够了：数据和配置都进清单、频率按能丢多少定、副本按 3-2-1 分开放、恢复定期真演练一遍。备份的价值不在“做了”，而在“出事那天能拿回来”，而这一点，只有演练过才算数。

（本文为个人运维实践记录。）