您可以演练的恢复清单

定义可接受的数据丢失和服务中断

写下可接受的最新恢复点和恢复有用服务的目标时间。这些是应用目标，而非 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；使用测试导出目标，切勿消费生产队列。

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

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

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

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