DynoTable
进阶阅读约 3 分钟

DynamoDB 备份与时间点恢复（PITR）完整指南

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

对审计日志而言这是不可协商的。它是一份不可变的合规记录；一次 重写事件的糟糕迁移，或一次意外的批量删除，都必须能够 恢复到出错前的那一刻。

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

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

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

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

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

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

备份与 PITR 如何工作

时间点恢复一旦启用，就会进行连续的自动备份。根据 AWS 文档， PITR 为你提供全托管的、按秒级恢复粒度的表数据连续 备份。窗口可 从 1 到 35 天 通过 RecoveryPeriodInDays 配置，你可以恢复 到其中的任意一秒 —— 直到大约落后实时五分钟处 （LatestRestorableDateTime）—— 包括恢复到不同的区域。

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

PITR 还是托管的导出到 S3的前提： 导出读取的是同一份连续备份，因此在 PITR 关闭时， ExportTableToPointInTime 会以 PointInTimeRecoveryUnavailableException 失败。

按需备份是独立的：手动的、你显式创建并 无限期保留的全表快照，适用于迁移前的检查点或一份 超出 35 天 PITR 窗口的长期合规存档。请求会被即时处理， 备份在几分钟内就可用于恢复，不消耗表的任何吞吐量， 而且你保留多少份都没有上限。文档里还有一条诚实的提醒： 按需备份不保证跨项目的因果一致性 —— 各次更新之间的偏差 “usually much less than a second”，但一份在写入尖峰中途拍下的 备份，并不是单一的冻结瞬间。

恢复带不回来的东西

恢复重建的是表的数据和它的索引 —— 而不是它周边的 运维配置。根据 AWS 文档， 你必须在恢复出的表上手动重新配置：自动扩缩策略、IAM 策略、 CloudWatch 指标与告警、标签、stream 设置、TTL、删除保护， 以及 PITR 本身。从备份恢复完却忘了重新启用 PITR —— 下一次 事故就是这样变得无法恢复的。

在恢复时，你可以有意地更改一部分设置 —— 计费模式、 预置容量、加密密钥 —— 也可以排除部分或全部二级索引； 如果你之后能把它们重建回来，这会让恢复更快也更便宜。恢复 还可以指向另一个区域，而且恢复永远不会覆盖一张已存在的表。

用 AWS Backup 做计划备份

DynamoDB 自带的按需备份没有调度器。要做带保留策略的 周期性备份，DynamoDB 与 AWS Backup 原生集成 （AWS 文档）： 备份计划为你提供带生命周期规则（包括冷存储分层）的计划备份、 用于容灾的自动跨账户与跨区域复制、通过备份保管库使用的 独立 KMS 密钥，以及能撑起一套谁也没法悄悄删除的 WORM 合规态势的 Vault Lock。两个运维上的坑：AWS Backup 需要 按账户、按区域显式选择加入，而它创建的备份（类型为 AWS_BACKUP）无法从 DynamoDB 控制台删除 —— 请到 AWS Backup 里管理它们。

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

PITR 恢复到 T-5 分钟校验后再切换audit-log（已损坏）audit-log-restored（新表）应用指向已恢复的表

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

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

stepresult
restore PITR to 09:59:00new table audit-log-restored with correct actions
diff against liveconfirm only the migration's rows differ
cut app over to restoredoriginal left intact for forensics

被破坏的表在你验证恢复时保持不动 —— 你把 恢复出的事件与实时事件对比，确认 action 值回来了，然后 把应用重新指向。恢复本身不会摧毁任何东西。

如果损失的是少数几个项目而非整表破坏，你可以 改为检查实时数据和恢复出的副本，只把受影响的行 拷贝过去 —— 参见复制 DynamoDB 表。

在 DynoTable 中操作

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

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

在 DynoTable 中检查一张 PITR 恢复出的 audit-log 表，以在切换应用之前验证恢复出的事件。
在 DynoTable 中检查一张 PITR 恢复出的 audit-log 表，以在切换应用之前验证恢复出的事件。

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

陷阱与后续步骤

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

那就闭合了审计日志的运维闭环：用事务保证一致性、用 Streams 做反应、用 TTL 做过期、用合适的容量模式控成本、用全局表实现 区域韧性，以及用 PITR 做数据恢复。重温 运维与成本概览，看看它们如何协同。

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

更新于