AWS RDS 备份与 PITR 恢复演练：从保留期、恢复命令到应用切换验证

数据库备份最常见的误区，是把"已经开启自动备份"当成"事故时一定能恢复"。真正可靠的备份策略，至少要回答四个问题：能恢复到什么时间点、恢复会生成什么资源、应用怎么切换、验证失败怎么回滚。

本文以 Amazon RDS 为例，整理一次可复用的 Point-in-Time Recovery（PITR）恢复演练流程。示例命令偏 MySQL/PostgreSQL 通用思路，实际参数要按自己的引擎、实例规格、VPC、安全组和子网组调整。

1. RDS 自动备份和 PITR 的基本边界

AWS 官方文档说明，RDS 会在备份窗口创建并保存自动备份；如果需要，可以在备份保留期内把 DB 实例恢复到指定时间点。保留期可设置为 0 到 35 天；设置为 0 会禁用自动备份。

另一个容易忽略的点：无论是从快照恢复，还是恢复到某个时间点，通常都是创建一个新的 DB 实例，而不是直接覆盖原实例。因此恢复演练必须包含应用连接串切换和回滚方案。

2. 先检查备份保留期

查看实例备份配置：

bash 复制代码

export DB_ID=prod-mysql-01
export AWS_REGION=ap-east-1

aws rds describe-db-instances \
  --region "$AWS_REGION" \
  --db-instance-identifier "$DB_ID" \
  --query 'DBInstances[0].{DBInstanceIdentifier:DBInstanceIdentifier,BackupRetentionPeriod:BackupRetentionPeriod,PreferredBackupWindow:PreferredBackupWindow,LatestRestorableTime:LatestRestorableTime,MultiAZ:MultiAZ}' \
  --output table

重点看三个字段：

BackupRetentionPeriod：是否大于 0。
PreferredBackupWindow：自动备份窗口。
LatestRestorableTime：当前最新可恢复时间。

如果 BackupRetentionPeriod=0，说明自动备份被关闭，此时无法做 PITR。生产库不建议这样配置。

3. 修改保留期

示例：把保留期设为 7 天。

bash 复制代码

aws rds modify-db-instance \
  --region "$AWS_REGION" \
  --db-instance-identifier "$DB_ID" \
  --backup-retention-period 7 \
  --apply-immediately

注意：AWS 文档中提到，从 0 改为非 0，或从非 0 改为 0，可能发生中断。因此生产环境不要在业务高峰期随手改；最好进入变更窗口并提前通知。

4. 执行 PITR 恢复到新实例

先记录 LatestRestorableTime，选择一个早于该时间的恢复点。例如：

bash 复制代码

export RESTORE_TIME="2026-07-31T06:40:00Z"
export NEW_DB_ID=prod-mysql-01-pitr-20260731

aws rds restore-db-instance-to-point-in-time \
  --region "$AWS_REGION" \
  --source-db-instance-identifier "$DB_ID" \
  --target-db-instance-identifier "$NEW_DB_ID" \
  --restore-time "$RESTORE_TIME" \
  --db-instance-class db.t4g.medium \
  --no-publicly-accessible

恢复后等待实例可用：

bash 复制代码

aws rds wait db-instance-available \
  --region "$AWS_REGION" \
  --db-instance-identifier "$NEW_DB_ID"

查询新实例 Endpoint：

bash 复制代码

aws rds describe-db-instances \
  --region "$AWS_REGION" \
  --db-instance-identifier "$NEW_DB_ID" \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text

5. 验证新库，不要直接切生产

拿到新实例后，先从堡垒机或应用同 VPC 的测试环境连接。

MySQL 示例：

bash 复制代码

mysql -h "$NEW_ENDPOINT" -u readonly_user -p -e "select now();"
mysql -h "$NEW_ENDPOINT" -u readonly_user -p -e "select count(*) from app.orders;"

PostgreSQL 示例：

bash 复制代码

psql "host=$NEW_ENDPOINT dbname=app user=readonly_user sslmode=require" -c "select now();"
psql "host=$NEW_ENDPOINT dbname=app user=readonly_user sslmode=require" -c "select count(*) from orders;"

建议验证：

能否从应用所在网络访问。
表结构是否完整。
核心表数据量是否符合恢复时间点预期。
应用只读启动是否成功。
慢查询、权限、参数组是否符合预期。

6. 应用切换策略

不要把恢复演练简化成"改一个数据库地址"。更稳的做法是：

先部署一套只读验证环境，连接新 DB。
用健康检查和核心接口确认数据可用。
若是灾难恢复，先冻结写入或进入维护模式。
更新 Secret Manager、Parameter Store、Kubernetes Secret 或应用配置中心里的连接串。
分批重启应用实例。
观察错误率、连接数、慢查询和业务指标。

如果验证失败，应用继续指向旧库；如果新库验证通过，再考虑切换写流量。

7. 回滚和清理

新库稳定前，不要立刻删除旧库。建议保留：

原实例。
恢复实例。
恢复时间点记录。
切换前后的应用配置快照。
操作人、时间、命令和验证结果。

清理前确认：

bash 复制代码

aws rds describe-db-instances \
  --region "$AWS_REGION" \
  --query 'DBInstances[].{id:DBInstanceIdentifier,status:DBInstanceStatus,endpoint:Endpoint.Address}' \
  --output table

8. 常见坑

8.1 以为 PITR 会覆盖原实例

通常不会。它会创建新的 DB 实例，所以应用连接串、DNS、Secret、网络权限都要纳入演练。

8.2 只恢复，不验证

恢复成功不等于业务可用。必须验证数据、权限、网络、安全组、参数组、应用启动。

8.3 备份保留期太短

如果只保留 1 天，周末发现周五误删数据时可能已经错过恢复窗口。保留期要结合 RPO/RTO、成本和业务风险定。

8.4 没有记录 LatestRestorableTime

恢复时间不能随便写，必须早于最新可恢复时间，并位于保留期内。

9. 总结

RDS 备份策略的最低要求，不是"开了自动备份"，而是定期做 PITR 恢复演练。演练要覆盖保留期检查、恢复命令、新实例验证、应用连接切换、回滚和清理。只有真正跑通过一次，事故时才不会在控制台里临时摸索。

参考资料

AWS 官方文档：Introduction to backups in Amazon RDS
AWS 官方文档：Backup retention period
AWS 官方文档：Restoring a DB instance to a specified time
AWS CLI 官方文档：restore-db-instance-to-point-in-time