备份之外，还要记得恢复

先区分“副本”和“恢复方案”

把一个目录复制到另一台机器，是备份工作的一部分。真正的恢复方案，还需要说明这些文件怎样重新组成一个可用的服务。如果只知道压缩包放在哪里，却不知道应该解开到哪个目录，遇到故障时仍然要临时猜测。

因此我会把“已经生成文件”和“能够恢复使用”分开看待。前者检查副本是否完整，后者检查数据、配置、程序版本和权限能否配合起来。两者都重要，只是不能互相替代。

一份简单的静态网站通常容易理解：页面、样式、图片和必要的服务器配置需要分别交代。有数据库的程序则更复杂，不能仅凭一个看起来很大的文件，就判断已经保存了全部内容。

做清单时，可以按用途而不是按目录顺序思考：哪些是用户生成的数据，哪些是可重新下载的程序，哪些是无法从别处还原的配置，哪些是访问外部服务所需的凭据。这样比较容易发现遗漏，也能避免把所有缓存一并长期保存。

例如，一个小站的源码可能已经保存在版本库里，但上传的附件未必在里面；部署说明可能写了域名，却没有交代证书与续期方式。看似“不属于正文”的文件，往往决定了网站能否被完整迁回去。

凭据应当单独保护。备份说明可以写清楚它们的存放位置和用途，但不要为了方便，把密码、令牌和私钥直接混进准备公开分享的源码包。

一个实用的名称可以包含项目、生成时间与范围，例如 notes-site-2026-10-29-content。名称不必装下所有细节，旁边再放一个说明文件，记录来源、包含内容、排除内容、检查结果和恢复入口。

时间需要说明口径。跨时区保存文件时，统一使用一种写法能减少排序和对照上的误会。保留完整年份，也能避免几个月之后分不清“10-11”指的是哪一天。

如果一次维护涉及多个服务，可以分别给它们编号，不要把所有内容都叫作“服务器备份”。未来恢复时，人通常先想起的是某个服务的名字，而不是当时归档它的目录。

传输结束后，先核对文件大小或校验值，确认目标位置得到的是同一份副本。接着尝试列出压缩包内容，检查关键目录是否存在。校验值能帮助确认文件在传输前后是否一致，但不能证明源文件本来就是一份可恢复的备份。

下一步才是内容检查。文字文件是否能正常解码，图片是否能打开，静态站的相对路径是否仍然成立？对于数据库，应当使用适合对应数据库与运行方式的备份方法，不能把复制一个运行中的数据文件当作通用答案。

检查过程最好也留下结果。比起只写“备份成功”，写“压缩包可列出、抽样文件可读取、恢复演练已完成”更能说明目前已经确认了什么。

演练不需要一上来就替换正式服务。可以先解开到一个独立目录，或者准备一个测试实例，只恢复最小的一部分数据。目标是确认步骤可以执行，而不是让生产环境承担试错成本。

静态站的演练可以从打开首页、正文和样式开始，再检查导航与图片。有后台服务的程序，需要继续检查账户、配置项、附件和外部依赖。测试环境也要避免自动向真实用户发送邮件或触发定时任务。

如果发现恢复过程中必须临时查找一个版本号或补一条命令，就把它写回说明。演练发现的问题越早变成文字，真正需要恢复时要重新做的判断就越少。

不同位置保存副本，可以降低单个存储位置出问题时的影响，但也会增加管理成本。需要知道哪些副本属于同一个版本，哪些已经过期，哪些因为特殊原因必须保留。不要只增加副本数量，却失去对它们的理解。

清理应当发生在新副本已经检查之后。先确认至少有一份可用的恢复点，再决定旧副本的保留范围。若备份包含个人资料或凭据，存放位置、访问权限与后续删除也要纳入维护计划。

最终值得追求的不是一个巨大的压缩包，而是一条短而清楚的恢复路径：从哪份副本开始，按什么顺序操作，如何确认恢复完成，以及不顺利时该停在哪里。