备份不是抄一份文件：给个人服务器做可恢复备份的三个检查点

很多人给服务器做备份，做法就是把目录打包一份、或者把数据库导出一份，看到文件生成了、大小也不小，就觉得安心了。可真正出事那天才发现：备份文件打不开、恢复到一半缺依赖、或者备份里压根没有最关键的那份配置。备份的目标不是“有一份副本”，而是“能在限定时间内把服务原样拉起来”。围绕这个目标，我平时会做三个检查。

一、先确认备份的范围，而不是先写脚本

备份最容易漏的不是数据文件，而是让数据“活过来”的东西。一台个人服务器上真正要备的通常有四类：第一是业务数据本身，比如数据库、上传文件；第二是配置，比如 Nginx、systemd 的 unit 文件、定时任务、环境变量文件；第三是密钥和证书，但这类东西要加密保存，不能和普通备份混在一起明文乱放；第四是恢复说明，哪怕只有几行，写清这台机器跑了什么、数据在哪、恢复顺序是什么。范围没定清，脚本写得再勤，也只是把“不完整”复制了很多份。

二、备份必须有校验，否则等于没备

每份备份生成后，至少要过两关。一是完整性校验：压缩包能不能正常解开、数据库导出文件能不能读到结尾，顺手记一个校验值，下次比对就知道文件有没有在传输或存储中损坏。二是隔离存放：备份不能只留在同一台机器上，机器一旦磁盘损坏或被入侵，备份会跟着一起没。哪怕只是同步一份到另一台机器或对象存储，也要和源数据分开。还有个细节是保留策略：别只留最新一份，上一次的损坏可能早已悄悄同步进新备份里，至少按天、按周各留几份，出问题时才有得退。

三、定期做一次恢复演练，这是最容易被跳过的一步

备份是否有效，只能用恢复来证明。不需要搞得很隆重：每隔一段时间，在一台临时机器或本地环境里，把最近的一份备份真正恢复一次——解开、导入、把服务启动起来、打开页面看一眼。演练会暴露很多平时想不到的问题：备份时少打了一个目录、恢复脚本依赖了源机器才有的工具、数据库版本对不上导不进去。这些问题在演练时发现只是麻烦，在故障时发现就是事故。

说到底，备份做得好不好，不看你存了多少份、占了多大空间，而看出事时你能不能按着记录一步步把服务恢复回来。范围定清、生成后校验、定期真恢复一次，这三件事做到了，备份才从“心理安慰”变成真正的兜底。