一份可以演练的恢复检查清单

定义可接受的丢失和中断

写下可接受的最新恢复点和恢复有用服务的目标时间。这些是应用程序目标，不是 PrivacyNodes SLA。如果丢失一小时数据不可接受，那么仅每日复制无法满足该目标。选择与您的工作负载和版本一致的数据库备份方法。

通过受保护的存储获取一次性目标、应用程序产物和授权的恢复凭据。确认谁批准恢复客户数据，以及测试环境如何阻止外部流量。不要覆盖运行中的生产数据库或现有目录。

清点完整的应用程序状态

对于报告 API，列出 PostgreSQL、上传文件、无法重新生成的导出、配置、加密密钥引用、DNS 和外部依赖。区分一次性缓存和保存需要核对的客户工作的队列。容器镜像描述的是软件，而不是所有持久状态。

了解备份包含什么

PostgreSQL 文档将逻辑转储、文件系统备份和连续归档描述为不同的策略。 pg_dump 归档覆盖一个数据库；集群范围的角色和表空间需要单独考虑。其客户端无法转储更新的主版本服务器。将工具版本和策略与目标匹配；复制活动数据目录并不自动保证一致性。

在恢复前检查归档。使用 pg_restore 选择表并不会自动包含其所有依赖。其 --clean 选项会删除现有对象；单事务恢复无法与并行作业结合使用。请针对特别确定的空测试数据库审查选项。

技术参考： PostgreSQL 备份和恢复 · PostgreSQL pg_dump · PostgreSQL pg_restore.

独立检查完整性和恢复

仓库检查和功能恢复回答不同的问题。restic 的普通 check 不会读取每个存储的数据包； check --read-data 会添加这些读取，并可能消耗大量带宽。两者都不能证明快照包含 API 所需的一切。

选择一个特定快照和一个新的目标目录。在共享仓库中，未限定的 latest 可能选择另一个工作负载。恢复可能覆盖文件，中断可能留下部分结果。先验证目标，保持生产文件和原始仓库不受影响。

技术参考： restic 仓库检查 · restic 恢复目标.

按依赖顺序测试恢复后的行为

重建环境，恢复数据库和匹配的上传文件，然后使用预发布凭据启动 API。保持工作进程暂停，直到了解其积压和副作用。禁用生产电子邮件、支付调用和 Webhook；使用测试导出目标，绝不消费生产队列。

使用已知测试账户读取一条记录、打开其上传文件、检查访问限制并运行一次小型新导出。验证另一个测试账户无法读取其数据。将所选恢复点与最新预期记录进行比较。演练后记录实际恢复时间；不要提前写下编造的成功结果。

在实际切换前解决写入所有权

在事件期间，决定哪个系统可以接受写入，以及之后如何核对更改。两个可写副本可能发生分歧。演练记录此决策，而不切换真实流量。演练结束时，根据您的保留规则删除一次性数据。

在每次排练后修正缺失的凭据、依赖和验证步骤。将运行手册保存在原始主机之外，并确保另一位授权维护人员能够找到它。可选的备份选项与此应用程序流程是分开的；在 服务事实中确认范围和恢复程序。使用 发布记录 用于随后的部署。