自托管服务清单与备份策略：恢复才是验收

服务器上服务不多时，人很容易相信自己记得一切：某个容器映射了哪个目录、数据库密码放在哪里、反向代理用了哪份配置。半年后再迁移，才发现真正关键的是不起眼的环境文件和上传目录。于是我给自托管环境建立了一份机器可读清单，并把“成功恢复”而不是“生成压缩包”作为备份验收。

先列出需要恢复的对象

每个服务记录域名、容器名、镜像版本、端口、持久卷、数据库、外部依赖、证书方式和负责人。数据按三类处理：可从代码重建的配置、必须保留的业务数据、可丢弃的缓存。只有第二类进入高频备份，第一类由 Git 与密钥仓库共同恢复，缓存不浪费空间。

以博客为例，至少包含数据库、附件目录、主题与插件配置、反向代理配置。单独备份数据库却忘记附件，恢复出来的文章会留下大量空图；只打包数据卷而不做数据库一致性处理，则可能得到不可用快照。

每日执行数据库逻辑备份与增量文件同步，每周生成一次完整归档，每月保留离线副本。归档在本机完成后立即计算校验值，再传到不同故障域。保留策略不是“永远不删”，而是日、周、月分层，定期检查容量与最旧可恢复点。

pg_dump -Fc -d app > app-$(date +%F).dump
sha256sum app-*.dump > SHA256SUMS

脚本开启 set -euo pipefail，每一步有明确退出码。上传成功不等于任务成功，远端对象大小和校验值都要核对；失败通知包含服务、备份点和最近一次成功时间。

每季度在隔离目录启动新数据库和临时容器，从零读取文档恢复。演练检查登录、文章数量、附件抽样、定时任务和对外链接。恢复过程记录 RTO（花了多久）与 RPO（最多丢多少数据），但不为好看而虚构目标。

密钥不能写进备份脚本。恢复环境通过专用密钥获取最小所需凭据，演练结束后销毁临时令牌。备份本身加密，解密密钥与备份存储分离，并保留应急访问说明。

备份是一条恢复链：发现故障、定位归档、取得密钥、准备环境、导入数据、切换流量、验证服务。任何一环只存在脑中，整条链就不可靠。清单让范围可见，自动化减少遗漏，定期演练则证明这些文件真的能把服务带回来。硬盘里有压缩包只代表完成了复制，恢复成功才代表拥有备份。