在AWS的NoSQL服务里，DynamoDB提供了连续备份（Point-in-Time Recovery，简称PITR）能力，允许我们把一张表恢复到过去三十五天内任意一个秒级时间点。很多团队在创建表时忽略了这项配置，直到发生误删或脏写才意识到损失无法挽回。通过UpdateContinuousBackups这个API，我们可以在表运行之后随时开启或关闭连续备份，而不需要重建表或者暂停业务流量。
UpdateContinuousBackups接口的基本结构与调用方式
从接口定义来看，UpdateContinuousBackups接收两个核心参数：TableName和PointInTimeRecoverySpecification。前者指明要操作的表名，后者是一个嵌套对象，里面的PointInTimeRecoveryEnabled布尔值决定了备份开关。当该值设为true时，DynamoDB会在后台启动流式捕获，把每一次写入、更新、删除操作持久化到独立的备份存储区，用户侧无需管理任何备份计划。
使用AWS CLI是最直接的验证方式。下面这段命令对名为Orders的表开启连续备份，返回结果中会包含最新的连续备份状态以及备份对应的时间范围：
aws dynamodb update-continuous-backups --table-name Orders --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
如果改用SDK，以Python的boto3为例，调用逻辑同样简单。需要注意的是，该接口属于控制面操作，调用频率受账户级别的API节流限制，但通常单次开启并不会触发限流。下面的代码演示了如何捕获返回并判断当前备份是否生效：
import boto3
client = boto3.client('dynamodb')
response = client.update_continuous_backups(
TableName='Orders',
PointInTimeRecoverySpecification={
'PointInTimeRecoveryEnabled': True
}
)
status = response['ContinuousBackupsDescription']
print(status['PointInTimeRecoveryDescription']['PointInTimeRecoveryStatus'])
从返回结构能看出，ContinuousBackupsDescription里包含两个子项：一个是持续备份整体状态，另一个是具体的PITR描述。只有当PointInTimeRecoveryStatus显示为ENABLED，才代表底层捕获流水线已经就绪。若返回ENABLING，说明系统仍在异步准备，此时尚不能执行精确时间点恢复。
开启连续备份所需的IAM权限与常见拒绝原因
不少开发者在本地用管理员账号测试一切正常，一到生产环境就用代码调用失败，根因往往出在权限策略上。UpdateContinuousBackups要求调用者拥有dynamodb:UpdateContinuousBackups这一具体操作权限，同时如果表使用了自带加密的KMS密钥，还需要kms:DescribeKey等相关授权，否则备份写入加密存储时会中断。
下面是一段最小化的IAM策略示例，仅允许对指定表开启连续备份。把Resource换成自己的表ARN即可。如果策略里漏掉了dynamodb:DescribeContinuousBackups，那么在调用Update之后想查询状态就会收到AccessDeniedException，这种问题在排障时容易被忽略。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateContinuousBackups",
"dynamodb:DescribeContinuousBackups"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}
]
}
另一个常见误区是认为开启连续备份必须表处于ACTIVE状态。实际上，表在UPDATING或者甚至刚从备份恢复的CREATING尾声阶段，也可以调用该接口，只是系统会排队处理。但若表正处于删除流程（DELETING），调用就会直接失败。因此在自动化脚本里，建议先通过DescribeTable确认表状态，再决定是否发起UpdateContinuousBackups请求，避免无谓的异常中断发布流程。
连续备份开启后的成本模型与恢复验证实践
开启PITR并不是免费功能。AWS会按照表在备份窗口内产生的数据变更量计费，也就是增量存储成本。对于写密集型业务，连续备份的费用可能接近甚至超过主表存储费用的一部分。因此在决定对大表全量开启前，最好先评估写入放大比，或对非核心表采用周期性OnDemand备份替代。
验证备份是否真正可用，不能只盯接口返回ENABLED。正确做法是在沙箱环境故意写入一条测试记录，等待几分钟让备份流水线捕获，然后调用RestoreTableToPointInTime把表恢复到写入之前的时间点，确认那条记录消失。下面代码展示了如何用boto3发起恢复，新表名必须不同于原表：
import boto3
from datetime import datetime, timedelta
client = boto3.client('dynamodb')
target = datetime.utcnow() - timedelta(minutes=10)
client.restore_table_to_point_in_time(
SourceTableName='Orders',
TargetTableName='Orders_Recovery',
RestoreDateTime=target
)
恢复出来的新表不会继承原表的连续备份设置，需要再次调用UpdateContinuousBackups去开启。此外，恢复操作本身也会产生一次性的数据读取费用。把这些成本与演练频率写进运维手册，才能让连续备份从配置项变成真正可依赖的容灾手段，而不是出了事才发现备份早就在某个权限变更后悄悄失效了。
DynamoDBUpdateContinuousBackupscontinuous_backups修改时间：2026-08-14 21:48:30