DynamoDB 备份与时间点恢复

DynamoDB 用两种方式保护你的数据。按需备份是你自行创建并可无限期保留的完整快照。 时间点恢复（PITR）是连续、自动的备份，让你能把表恢复到一个滚动窗口内的任意一秒。 两者都恢复到一张新表 —— 它们是恢复工具，不是一个撤销按钮。

对于审计日志，这一点没有商量余地。它是一份不可变的合规记录；一次重写了事件的糟糕迁移， 或一次意外的批量删除，都必须能被恢复到犯错之前的那一刻。

DynamoDB 备份与时间点恢复是如何工作的？

DynamoDB 提供两种备份类型。时间点恢复（PITR）进行连续的自动备份，让你能恢复到可配置的 1 至 35 天窗口内的任意一秒。按需备份则是手动的完整快照，可无限期保留。两者都会恢复到一张新表，绝不覆盖原表，因此它们是恢复工具，而不是就地撤销。

• PITR = 连续备份，可恢复到任意一秒，窗口可配置为 1 到 35 天（过去它固定为 35 天）。
• 按需备份 = 手动的完整快照，可按你的意愿保留多久就保留多久，与 PITR 的窗口相互独立。
• 恢复会创建一张新表。 你恢复到一个新名字，然后再切换过去 —— 原表保持原样。
• PITR 按表大小计价，而不是按恢复点的数量 —— 用 DynamoDB 定价计算器来估算它。

问题所在：一个你无法就地撤销的错误

DynamoDB 没有可以回滚的事务日志，也没有对写入的“撤销”。如果一个迁移脚本重写了每个事件的 action 字段，或者有人执行了一次比预期更宽的删除，那张表就只是处于错误的状态。没有备份， 数据就没了。

对于审计日志 —— 其全部价值就在于成为一份可信赖的记录 —— “我们拿不回上周二的事件”是一次 合规失败，而不只是一点不便。

备份和 PITR 如何工作

时间点恢复一旦启用，就会进行连续的自动备份。据 AWS 文档所述， PITR “提供完全托管、自动且连续的表数据备份，恢复点最多达 35 天、粒度精确到秒”。该窗口可通过 RecoveryPeriodInDays 在 1 到 35 天之间配置，你可以恢复到其中的任意一秒 —— 包括恢复到一个 不同的区域。

有一个重要的边界情形：缩短恢复周期会立即拉近最早的恢复点，而禁用后再重新启用 PITR 会重置可恢复的起始时间 —— 你会丢失之前的连续历史。

按需备份是独立的：手动创建、可无限期保留的全表快照，适合作为迁移前的检查点，或作为 超出 35 天 PITR 窗口的长期合规归档。

两者都恢复到一张新表，而不是覆盖到现有表上：

一个实战示例：从一次糟糕迁移中恢复

一次本意是添加 expiresAt 属性的迁移，反而把每个事件的 action 都覆盖成了空字符串。PITR 已开启、窗口为 35 天，于是你恢复到迁移运行之前的那一秒：

在你验证恢复期间，被损坏的表保持原样 —— 你把恢复出的事件与线上事件对比，确认 action 值 已经回来了，然后再把应用切过去。恢复本身不会销毁任何东西。

如果损失的只是少数几个项而非整表损坏，你可以改为检查线上数据和恢复出的副本，只把受影响 的那些行复制过来 —— 参见复制 DynamoDB 表。

在 DynoTable 中操作

一次恢复的价值取决于你对它的验证。在恢复到 audit-log-restored 之后，你需要真正去查看恢复 出的事件，确认它们与犯错之前本应有的样子相符。

DynoTable 能像连接任何其他表一样连接到恢复出的表，因此你可以查询受影响租户的事件、确认 action 值正确，并在切换之前与线上表对比 —— 把一次恢复从一场信心的豪赌变成一次经过验证的 恢复。

你还可以把恢复出的事件导出，作为一份离线的合规记录 —— 参见 把 DynamoDB 导出到 CSV。

坑与后续步骤

• 在你需要它之前就启用 PITR。 它只从开启的那一刻起提供保护 —— 不存在追溯性恢复。对于 任何你承受不起丢失其数据的表，都把它打开。
• 禁用 PITR 会重置窗口。 把它关掉再重新打开会抹去连续历史；可恢复的起始时间从重新启用 那一刻起重新计算。
• 恢复既不是瞬时的也不是免费的。 一次恢复会预置一整张新表，所需时间与大小成正比；为 这段时长和那张额外的表做好预算。
• 35 天不是归档。 对于超出 PITR 窗口的保留需求，请做按需备份或导出到 S3 —— PITR 是一个 恢复窗口，而非长期存储。

这就闭合了审计日志的运维环路：事务用于一致性、Streams 用于反应、TTL 用于过期、合适的容量 模式用于成本、global tables 用于区域韧性，而 PITR 用于数据恢复。回顾 运维与成本概览，看看它们如何拼合在一起。

下载 DynoTable，连接到一张恢复出的表，在你信赖它之前验证你的恢复。