DynamoDB没有传统数据库意义上的回收站，DeleteTable执行成功后，原表名下的所有数据、二级索引、流配置都会被彻底清除。很多团队在误删表之后才第一次认真思考备份问题，结果发现没有任何可用的恢复点，数据彻底丢失。要能在删除后找回数据，唯一的出路是事前开启按需备份（快照）或者时间点恢复（PITR），本文完整梳理这两种恢复机制的原理和操作步骤。
一、先弄清楚DynamoDB的两种备份机制
第一种是按需备份（On-demand Backup），也就是通常说的快照。你对某张表执行创建备份的操作后，DynamoDB会在后台生成一份全量快照，这份快照包含表的数据、索引结构、表配置等信息。按需备份是长期保留的，你不主动删除它，它就一直存在，适合做每周归档、上线前留底这类场景。需要注意，按需备份目前不收费，这是DynamoDB比较良心的一点。
第二种是时间点恢复（Point-in-Time Recovery，简称PITR）。开启后DynamoDB会持续保留最近35天的变更流，你可以把表恢复到这35天内任意一秒的状态。PITR按月收费，价格和表的数据量有关。两者的关键差异在于：按需备份是手动触发的静态快照，保留期由你决定；PITR是滚动的35天窗口，超过35天的状态无法恢复。
误删场景下，如果删除之前表开启了PITR，恢复时要特别注意一点：删除操作会连带清除PITR记录，所以恢复的目标时间点必须选择在删除操作发生之前。只要时间点选对了，整张表可以完整还原。
二、从按需备份快照恢复表的完整操作
先确认你手里有可用的备份。可以在控制台的表详情页进入Backups标签查看，也可以用CLI列出：
# 查看指定表的所有备份
aws dynamodb list-backups \
--table-name Orders
# 查看全部备份（跨所有表）
aws dynamodb list-backups \
--time-range-lower-bound 2024-01-01T00:00:00+08:00
找到目标备份的ARN之后，执行恢复命令。恢复不是原地覆盖，而是生成一张全新的表：
# 从指定备份恢复到一张新表
aws dynamodb restore-table-from-backup \
--target-table-name Orders-restored \
--backup-arn arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders/backup/01234567891234-abcdef
# 如果希望新表开启加密或改计费模式，可以附加参数
aws dynamodb restore-table-from-backup \
--target-table-name Orders-restored \
--backup-arn arn:aws:dynamodb:ap-northeast-1:123456789012:table/Orders/backup/01234567891234-abcdef \
--billing-mode-override PAY_PER_REQUEST \
--sse-specification-override Enabled=true,SSEType=KMS
几个容易踩的坑要提前知道。第一，新表名不能和现存表重名，如果想让应用切回原来的表名，需要先把当前残缺的同名表删掉或者改名流程处理后再改回来。第二，恢复过程中新表的状态是CREATING，期间不能写入。第三，恢复出来的表不会自动继承原表的自动扩缩配置、标签和流开关，需要手工补配。第四，恢复完成不代表索引立即可用，全局二级索引的数据是在后台异步回填的，表状态变为ACTIVE后索引可能还在构建中。
三、通过PITR把表恢复到删除前的某一秒
如果之前开启了PITR，恢复命令更直接，指定一个删除发生之前的时间点即可：
# 开启PITR（事前操作，误删后无法再开启）
aws dynamodb update-continuous-backups \
--table-name Orders \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
# 恢复到删除前的某一时刻，注意时间必须在删除操作之前
aws dynamodb restore-table-to-point-in-time \
--source-table-name Orders \
--target-table-name Orders-restored \
--restore-date-time 2024-03-15T14:30:00+08:00
如果不传--restore-date-time，系统默认恢复到最近的可恢复时间点（LatestRestorableDateTime），这在误删场景下反而危险，因为最新的可恢复点可能已经接近删除时刻，最好显式指定一个确认安全的时间。可以用下面的命令查看当前可恢复的时间窗口：
aws dynamodb describe-continuous-backups \
--table-name Orders \
--query 'ContinuousBackupsDescription.PointInTimeRecoveryDescription'
返回结果里包含EarliestRestorableDateTime和LatestRestorableDateTime，你的目标时间必须落在这个区间内。PITR恢复出来的同样是一张新表，原表的流、标签、自动备份策略等元数据同样不会自动带过来。
四、生产环境的备份策略建议与恢复演练
单纯依赖某一种机制都有盲区。PITR只覆盖35天，且删除后记录随之清空；按需备份依赖人工触发，容易忘。比较稳妥的组合是：核心表全部开启PITR应对近期误操作，同时用EventBridge Scheduler定时触发create-backup做每日或每周快照，实现长期保留。示例如下：
# 通过定时任务对核心表创建快照
aws dynamodb create-backup \
--table-name Orders \
--backup-name "Orders-daily-2024-03-15"
另一个常被忽视的环节是恢复演练。备份有没有真的成功、恢复要花多久、恢复后索引回填需要多长时间，这些问题只有实际跑一遍才有答案。大表的恢复时间可能长达数小时，直接决定了你的恢复目标时间（RTO）能不能达标。建议每季度挑一张表做一次恢复演练，把恢复耗时、验证清单、切换步骤整理成文档。
最后提醒一点权限层面的风险：能执行DeleteTable的角色和能执行备份删除的角色要严格控制，最好通过SCP或IAM策略限制生产表的删除权限，从源头上降低误删概率。备份机制是兜底，权限治理才是第一道防线。
DynamoDB表恢复快照备份PITR修改时间：2026-09-12 22:28:34