3、AWS备份服务：AWS Backup功能介绍、备份策略配置、跨区域备份
说到云上备份，很多朋友第一反应是「自己写脚本、搭定时任务、再搞个S3生命周期」。嗯，我以前也是这么干的。直到有一次，我负责的一个生产环境因为脚本权限问题，备份任务半夜静默失败了，整整三天没人发现……那感觉，真不好受。
后来AWS推出了AWS Backup，说白了就是帮你把备份这件事「托管」了。你不用再操心调度、权限、加密这些琐事。我个人习惯，现在但凡新项目，只要能用AWS Backup，绝不用自建方案。省心，真的省心。
3.1 AWS Backup功能介绍
AWS Backup是什么？它是一个全托管的备份服务。你可以把它理解成一个「备份中央控制台」。它能统一管理EC2、EBS、RDS、DynamoDB、EFS、FSx、Storage Gateway……几乎所有AWS存储类服务的备份。
我总结一下它的核心能力：
- 统一策略管理：一套备份策略，管所有资源。不用每个服务单独配。
- 自动化调度：按小时、天、周、月、甚至cron表达式来跑备份。
- 生命周期管理：自动把备份从冷存转到冷存，或者到期删除。
- 跨区域复制：这是灾备的关键。备份自动复制到另一个Region。
- 合规与审计：所有备份操作都有CloudTrail日志，方便审计。
- 加密：默认用KMS加密，你也能用自己的密钥。
核心价值：AWS Backup最大的好处是「一致性」。你想想看，以前RDS备份一套逻辑，EBS快照另一套逻辑，EC2镜像又一套。出了问题排查起来头大。现在全统一了，一个控制台、一套API、一套IAM权限。
3.2 备份策略配置
备份策略，在AWS Backup里叫Backup Plan。我建议你把它当成一个「模板」。你定义好规则，然后关联到资源上就行。
配置一个备份策略，核心就三步：
- 定义备份规则：频率、保留时间、备份窗口。
- 选择资源分配：按标签、按资源ID、或者按资源类型。
- 设置生命周期：冷存转换、过期删除。
举个例子，我常用的一个生产环境备份策略：
{
"BackupPlanName": "Production-Daily-Backup",
"Rules": [
{
"RuleName": "DailyBackup",
"TargetBackupVaultName": "Production-Vault",
"ScheduleExpression": "cron(0 2 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 120,
"Lifecycle": {
"DeleteAfterDays": 30,
"MoveToColdStorageAfterDays": 7
},
"RecoveryPointTags": {
"Environment": "Production",
"BackupType": "Daily"
}
}
]
}
这段配置的意思是：每天凌晨2点开始备份，窗口期1小时，完成时间2小时。备份保留30天，7天后转入冷存。嗯，这里要注意，冷存有最低存储费用，如果你的备份很小，可能不划算。
我的经验：备份窗口别设太紧。我曾经设过15分钟的窗口，结果有一次RDS实例很大，备份没跑完就被截断了。后来我改成60分钟，再也没出过问题。建议根据数据量，留出至少30%的余量。
配置好策略后，你需要创建一个备份资源分配。我习惯用标签来管理。比如给所有生产环境的EC2打上 Backup:Daily 标签，然后策略里直接按标签匹配。这样新加的资源只要打上标签，自动就被保护了。
3.3 跨区域备份
跨区域备份，是灾备的「最后一道防线」。你想想看，如果整个Region挂了，本地备份再完整也没用。所以，必须把备份复制到另一个Region。
AWS Backup实现跨区域备份有两种方式：
- 方式一：在备份策略里直接配置跨区域复制
- 方式二：手动或自动触发复制任务
我个人强烈推荐方式一。直接在Backup Plan里加一个 CopyAction 就行。比如：
{
"CopyActions": [
{
"DestinationBackupVaultArn": "arn:aws:backup:us-west-2:123456789012:backup-vault:DR-Vault",
"Lifecycle": {
"DeleteAfterDays": 90,
"MoveToColdStorageAfterDays": 30
}
}
]
}
这段配置的意思是：每次备份完成后，自动复制到 us-west-2（俄勒冈）区域的 DR-Vault 里。保留90天，30天后转冷存。
避坑指南：我曾经踩过一个坑——跨区域复制会产生数据传输费用。如果你每天备份几百GB的数据，跨区域复制费用可能比备份本身还贵。建议提前算好成本，或者只复制关键数据的备份。
另外，跨区域备份还有一个「隐形的坑」：IAM权限。源区域的备份服务需要有权限写入目标区域的备份仓库。我建议你创建一个专门的跨区域备份角色，把权限收窄。比如：
{
"Effect": "Allow",
"Action": [
"backup:CopyIntoBackupVault",
"backup:DescribeBackupVault"
],
"Resource": "arn:aws:backup:us-west-2:*:backup-vault:DR-Vault"
}
嗯，这里要注意，不要用通配符。我见过有人直接给了 backup:*，结果不小心把生产环境的备份仓库也覆盖了。权限越小，风险越小。
3.4 实战建议与最佳实践
最后，我总结几条实战中沉淀下来的建议：
- 先做小范围测试：别一上来就全量配置。先拿一个非生产环境的RDS试试，确认备份能恢复。
- 定期做恢复演练：备份好不好，恢复才知道。我每季度会做一次恢复测试，确保流程没问题。
- 监控备份状态：用CloudWatch监控备份失败事件。我设了一个SNS通知，一旦备份失败，立刻发短信给我。
- 标签管理要规范：标签是关联策略的核心。我建议团队统一标签命名规范，比如
BackupPolicy:Daily、BackupPolicy:Weekly。 - 加密不要忘：默认用AWS托管密钥就行。如果合规要求高，用自己管理的KMS密钥。
一句话总结：AWS Backup不是万能的，但它能帮你把备份这件事从「手工活」变成「自动化流水线」。你只需要定义好策略，剩下的交给它。但记住，备份策略再完美，不验证恢复流程，等于白做。
好了，这一章就到这里。下一章我们会聊聊跨区域灾备架构设计，包括如何用Route 53做DNS故障转移、如何用RDS跨区域只读副本做读写分离。到时候见。