DynamoDB 的时间点恢复（Point-in-Time Recovery，简称 PITR）提供了一种持续备份机制，可以将表数据恢复到过去 35 天内的任意一秒。当发生误删数据、程序逻辑错误导致批量脏写，或者需要回溯分析某一时刻状态时，PITR 能避免全量快照带来的长时间恢复窗口。PITR 不会影响表的正常读写性能，恢复时生成一张全新的表，原表保持不变，因此可以安全地对比数据或进行灰度切换。
一、PITR 的能力边界与启用方式
PITR 的实现基于 DynamoDB 内部的连续日志记录，而不是周期性的快照。每次写入操作都会产生可回放的变更记录，系统据此维护过去 35 天内所有可恢复的时间点。恢复粒度可以达到秒级，但实际可恢复的最早时间取决于表启用 PITR 的时间。只有启用 PITR 之后的时间范围才会被记录，启用前无法恢复。
在创建新表时，可以在控制台的备份选项区域直接勾选启用时间点恢复。对于已经存在的表，也可以通过 AWS 管理控制台、CLI 或 SDK 开启。开启过程不会中断表的读写请求，也不会额外消耗读写容量。开启后，表的 ContinuousBackupsStatus 会变为 ENABLED，系统开始持续记录变更。
以 AWS CLI 为例，为已有表开启 PITR 的命令如下：
aws dynamodb update-continuous-backups \
--table-name Orders \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
执行成功后，可以使用 describe-continuous-backups 查看可恢复窗口。该接口会返回 EarliestRestorableDateTime 和 LatestRestorableDateTime 两个时间值，前者通常是启用 PITR 的时刻，后者则是约 5 分钟前的当前时间。这个窗口会不断向前滚动，超过 35 天的记录自动失效。
二、执行时间点恢复的完整步骤
恢复操作的核心是把源表在指定时间点的数据重新生成到一张新表。新表必须使用与源表不同的表名，不能原地覆盖。恢复时可以选择恢复到某个精确的历史时间，也可以直接使用最新的可恢复时间。恢复任务提交后，新表会先进入 CREATING 状态，通常需要几分钟到几十分钟，具体取决于数据量大小和索引数量。
控制台操作路径比较简单：在 DynamoDB 表列表中选择源表，进入备份选项卡，点击恢复到时间点，然后填写目标表名并选择恢复时间。对于自动化运维场景，CLI 命令如下：
aws dynamodb restore-table-to-point-in-time \
--source-table-name Orders \
--target-table-name Orders_Restored_20240917 \
--restore-date-time 1693526400
其中 restore-date-time 参数接收 Unix 时间戳，单位为秒，必须是可恢复窗口内的时间。如果不确定时间戳，可以先用 date -d "2024-09-17 10:00:00" +%s 在 Linux 或 macOS 上转换。若想直接恢复到最新状态，可以将 restore-date-time 替换为 use-latest-restorable-time 并省略时间戳参数。
通过 SDK 也能完成同样操作。以 Python 和 boto3 为例：
import boto3
import time
client = boto3.client('dynamodb')
response = client.restore_table_to_point_in_time(
SourceTableName='Orders',
TargetTableName='Orders_Restored_' + str(int(time.time())),
RestoreDateTime=1693526400
)
print(response['TableDescription']['TableStatus'])
恢复出的新表会保留源表的本地二级索引（LSI）和全局二级索引（GSI），数据会同步恢复到目标时间点。但新表的初始容量模式默认沿用源表设置。如果源表是固定容量模式，恢复过程中写入新表会消耗目标表的写入容量；如果表数据量很大，建议在恢复前将目标表设为按需容量模式，避免因限流导致恢复时间拉长。
三、PITR 与按需备份的差异及选择策略
DynamoDB 提供两种原生备份手段：时间点恢复（PITR）和按需备份（On-Demand Backup）。PITR 的优点是恢复粒度细、备份持续自动进行，适合防止误操作和逻辑错误；缺点是保留期固定为 35 天，且恢复只能在同一区域完成。按需备份则生成完整的表快照，可以永久保留，也可以跨区域复制，但恢复粒度取决于创建快照的频率。
成本方面，PITR 按备份存储的数据量计费，费用与表的总大小和写入变化量相关，启用后即使没有执行恢复也会产生费用。按需备份同样按存储量计费，但可以手动删除过期快照来控制成本。对于核心业务表，通常建议同时开启 PITR 并定期创建按需备份，PITR 负责短期细粒度恢复，按需备份负责长期归档和跨区域容灾。
如果需要跨区域恢复，单纯使用 PITR 无法实现，必须先将按需备份复制到目标区域，再在目标区域从备份恢复新表。另外，PITR 恢复出的新表不会自动继承源表的自动伸缩策略、标签、CloudWatch 告警、DynamoDB Streams 配置以及 TTL 设置。也就是说，恢复后的表可能看起来数据完整，但周边配置需要重新补齐。
四、恢复后的配置补全与常见问题
恢复完成后，第一件事就是检查新表的索引状态和数据正确性。虽然 LSI 和 GSI 会被恢复，但索引的容量设置、自动伸缩策略不会继承。如果源表开启了 DynamoDB Streams，新表默认不会启用流，需要手动开启并重新配置 Lambda 触发器或 Kinesis 适配器。标签和 CloudWatch 告警也需要重新绑定，避免监控盲区。
另一个常见问题是时间戳超出窗口。DynamoDB 对无效的 RestoreDateTime 会返回 ValidationException。恢复前建议先调用 describe-continuous-backups 获取 EarliestRestorableDateTime 和 LatestRestorableDateTime，确保时间戳落在窗口内。删除源表会同时删除其 PITR 记录，因此如果要在删除表后保留恢复能力，必须先通过按需备份生成快照。
最后需要关注恢复期间的目标表容量消耗。如果目标表采用固定写入容量，大量数据写入可能触发限流，延长恢复时间。推荐的做法是：在恢复命令提交前创建一张按需容量模式的新表，或者将目标表的写入容量调到较高值，恢复完成后再调整回正常水平。验证数据时，可以通过对比恢复表与源表中关键分区的数据量、抽样主键记录等方式确认一致性。
掌握这些细节后，PITR 就能成为 DynamoDB 数据保护体系中非常可靠的一环。它把误删恢复从小时级的手工导出导入压缩到分钟级，并且恢复过程不会影响线上业务，是每个 DynamoDB 使用者都值得启用的能力。