备份目标由 RPO、RTO 和一致性范围定义
“每天有一个压缩包”不是恢复目标。团队先明确最多能丢失多长时间的数据即 RPO，以及从事故确认到核心服务恢复的 RTO。还要列出一致性范围：PostgreSQL、用户上传、加密配置、应用 release、迁移版本和外部依赖标识哪些必须组合恢复。只备份数据库而遗漏媒体，会得到大量断开引用；只复制上传目录又无法知道它对应哪一时刻的表状态。
不同数据采用不同机制时，需要共同恢复点或可验证补偿。数据库逻辑备份期间媒体仍变化，可以在备份清单记录截止时间与文件哈希，再通过不可变媒体策略保证历史文件仍可取；也可以短暂冻结相关写入。方案必须写出恢复后如何处理备份点之后的消息、邮件和支付，不让外部系统因为数据库回退而重复执行。恢复目标是业务一致，不只是 SQL 能导入。
备份产物携带不可篡改清单和版本
每次备份生成唯一 id，清单记录开始结束时间、数据库版本、迁移集合、应用 release、文件数量与总字节。数据库 dump、媒体归档和清单分别计算 SHA-256，再对整体清单认证或签名。文件名和目录列表不能作为完整性证明，传输截断、错误覆盖和存储位翻转都可能保持名字不变。恢复程序在解密和解压后重新计算哈希，不一致立即停止。
备份过程的成功条件包括命令退出码、产物非空、清单完整与远端持久化确认。脚本不能把管道前段失败被后段成功掩盖，所有命令使用严格错误传播。日志只记录备份 id、大小、耗时、目标存储摘要和结果，不打印数据库密码或加密密钥。上传后执行独立只读校验，避免本地临时文件正确而远端对象损坏。
加密密钥与备份分离且可被演练取得
备份包含生产数据时必须在离开受控主机前加密，使用经过审查的认证加密方案并为每个产物生成唯一随机参数。密钥存放在与备份不同的受限系统，源码、命令行、普通日志和同一个云存储桶都不是合适位置。只由单个管理员记住密钥位置也会形成不可恢复风险，访问流程需要双人或应急授权，同时记录取用审计。
密钥轮换要保留解密历史备份的版本映射，不能删除旧密钥后才发现保留期内产物全部失效。演练使用真实权限流程取得密钥副本，证明值班人员在目标时间内能够完成，而不是提前把明文密钥放进测试环境。解密只在隔离恢复主机的受限临时目录进行，结束后安全清理，并确认 shell 历史、进程参数和报告不包含秘密。
恢复环境必须与生产写路径隔离
定期演练在一次性隔离网络中创建数据库和上传目录，使用与正式部署相同的非交互账户运行恢复脚本。DNS、SMTP、支付、对象存储写端点和消息代理必须指向不可写替身，防止恢复的定时任务把旧邮件重新发送或消费真实队列。恢复主机容量至少覆盖解密产物、展开副本、数据库重建和索引空间，不能到一半才发现磁盘不足。
恢复脚本要求精确备份路径和显式确认，拒绝通配符与模糊“最新”选择。导入前验证清单和版本兼容，创建全新目标而不是覆盖一个未知环境。若步骤失败，保留受限诊断目录与日志，后续重试从清晰阶段开始；不要在失败钩子里递归删除整个恢复根目录。正式灾难恢复若确需替换生产，也先再次解析绝对目标并建立恢复前快照。
数据库、媒体与 release 按兼容顺序组合
先恢复原始备份对应的数据库与媒体，再启动清单记录的应用 release 做基础验证。直接用最新代码打开旧 schema，可能自动迁移并掩盖备份本身是否可用；旧代码连接已升级 schema 同样危险。确认基线可读后，才能按正常发布流程逐步执行迁移与构建，每一步保留退出码和版本证据。上传目录权限、符号链接和媒体哈希也要恢复，不能只看文件数量。
PostgreSQL 逻辑恢复应使用遇错退出，并检查扩展、角色、所有者和权限是否符合目标环境。恢复成功后运行只读一致性查询：文章、分类、媒体引用、修订和审计数量与备份快照匹配，抽样关联不存在孤儿。序列、默认值和索引有效性也要检查，能 SELECT 几行不代表后续 INSERT 正常。若使用时间点恢复，还要验证目标时间与 WAL 连续性。
业务验收用快照基准而非绿色健康页
演练前从源系统生成脱敏基准，包括关键表计数、部分聚合、随机样本哈希和媒体 SHA-256。恢复后用同一查询比较，允许差异必须由备份截止时间解释。应用健康检查覆盖真实数据库查询、公开文章读取、后台计数和媒体响应，不只确认端口返回 200。RSS、搜索索引等可再生数据要么验证已经恢复，要么证明重建脚本在 RTO 内完成。
还要执行最小写入冒烟：在隔离环境创建一条带修订和审计的测试记录，再安全回滚或删除，确认权限、序列和事务路径可用。不要修改恢复的业务样本来做测试，否则后续哈希对账失去基准。验收记录每项命令、预期、实际结果和耗时，任何缺失媒体、权限错误或迁移失败都判演练失败，不能因首页能打开而降级为成功。
失败演练覆盖损坏、缺密钥与部分恢复
主动截断归档、修改一个媒体字节和提供错误密钥，恢复程序必须在写入目标前失败并给出不含秘密的明确阶段。移除清单中的一个文件、模拟数据库导入中断和磁盘写满，确认不会留下被误标为可用的半恢复环境。若脚本支持重试，应从重新验证产物开始，不能相信上次解压目录。恢复失败本身也要进入告警和演练报告。
灾难场景包括主机丢失、备份存储暂时不可用、密钥管理员缺席和最新备份损坏。流程要能选择上一份已验证备份并量化额外数据损失，而不是无限等待单一副本。至少保留一份与生产故障域隔离的副本，并定期验证访问权限没有因账户轮换失效。勒索场景还要求备份不可由应用账户批量删除，保留策略变更受独立授权。
报告把可恢复性变成持续指标
每次演练报告记录备份 id、截止时间、参与 release、恢复环境、各阶段耗时、RPO/RTO 是否满足、数据差异和未解决问题。不要在报告附带明文配置、用户样本或密钥位置。问题要有负责人和复测日期，例如“媒体恢复慢”应拆成吞吐基准、瓶颈和目标，而不是笼统建议扩容。连续演练结果可观察备份增长与恢复时间趋势，提前发现 RTO 被数据规模侵蚀。
通过一次演练后仍需按固定周期和重大 schema、存储或加密变更触发复测。随机抽取不同保留年龄的备份，避免永远只验证最新产物。清理策略只删除已经满足保留规则且有其他可用副本的文件，并记录精确对象和结果。真正的“备份成功”应由最近一次隔离恢复证据支持；没有恢复日期、数据基准与业务冒烟的绿色图标，只能证明脚本曾经写过文件。
外部系统与恢复后增量需要单独对账
数据库回到过去时，备份点之后已经发送的邮件、支付、Webhook 和消息不会自动回退。恢复计划列出每类外部副作用的操作键与查询方式，重新开放工作者前先对账。历史 outbox 可能再次出现，消费者幂等记录的保留期必须覆盖可恢复备份年龄；否则旧事件会被当作新动作执行。无法查询的高风险动作进入人工队列，不用批量重放碰运气。
备份点后的合法业务增量如果保存在消息日志或审计流中，要定义恢复后重放顺序和 schema 兼容。先验证基线快照，再按稳定事件 id 应用增量，每个聚合拒绝版本倒退。重放工具默认只读预览数量、时间范围和副作用类型，执行有速率限制与审计。直接把最新应用连到旧库并启动全部定时器，会在尚未对账时扩大损失。
域名、证书、对象存储和第三方凭据可能不在数据库备份中，却决定恢复服务能否真正接管。清单记录它们的版本与安全获取位置，不把秘密本身放进报告。演练验证 DNS 切换权限、证书部署和依赖沙箱，但禁止向真实用户发送。RTO 分阶段计算：数据恢复、应用启动、对账、只读开放和完全写入分别记录。
演练结束要销毁隔离数据与临时密钥，保存的只是脱敏证据和问题清单。清理脚本解析精确环境 id，确认不是生产再执行，不能用宽泛目录或云资源通配符。销毁失败本身进入报告。可恢复性与演练安全同等重要，一次恢复测试若把生产消息误发或遗留可访问数据，就不能算成功。
实现片段
pg_restore --exit-on-error --single-transaction backup.dump
评论 · 0