发布于: Aug 8, 2022
Amazon Web Services Backup 为您提供最佳的云备份解决方案，下面我们以七个实例来为您介绍 Amazon Web Services backup 的使用：
policy][Number]
resource/Application][Backup policy][Number]
最佳实践五：对于一次性备份需求的管理。一次性备份（One-time
backup）或者称为（On-demand backup）是指临时性的一些备份需求。资源的拥有者需要提备份申请给运维团队来操作备份，提申请时需要指定备份资源和保留日期。以下是一个申请的示例：
Amazon Web Services RDS 同时支持两种方式的备份，一种是自动备份（Automated Backup），对应任意时间点的恢复 PITR（Point-in-Time Restore），一种是手工快照备份（Manually Snapshot），对应快照时间点的恢复（Snapshot Restore）。RDS 的控制台上可以管理这两种备份方式。控制台的Automated Backup菜单上，可以查看数据库的可恢复时间点（Latest Restorable Time和Earliest Restorable Time）。
Amazon Web Services Backup 同时支持 RDS 的这两种备份方式（注意：暂不支持 Amazon Web Services Aurora 的持续备份和 PITR，只支持 Aurora 的快照备份）。Amazon Web Services Backup 中将 RDS 的自动备份称为连续备份（Continuous Backup）。连续备份的数据保留时间为 1～35 天，备份的颗粒度是 1 秒。周期性快照备份的最小频率是1小时，数据保留时间最长为 100年。
有两个需要特别注意的地方。注意点一：Amazon Web Services Backup 的持续备份的优先级高于 RDS 的自动备份，如果在备份计划中开启了连续备份功能，则 RDS 的自动备份设置将失效，会使用 Amazon Web Services Backup的连续备份设置。RDS 控制台上会提示自动备份已经被 Amazon Web Services Backup 所接管，如下图：
注意点二：RDS 数据库的自动备份功能必须处于开启状态，即自动备份的保留天数不能为 0。否则在 Amazon Web Services Backup 的备份计划中启用连续备份将不会起作用。
用户可以用两种方法来管理 RDS 的日常备份：方法一：在 RDS 控制台上设置自动备份，用 Amazon Web Services Backup 管理周期性快照备份。方法二：在 Amazon Web Services Backup 上同时管理 RDS 的自动备份和周期性快照备份。建议采用方法二，即在 Amazon Web Services Backup 上同时管理RDS的自动备份和周期性快照备份，这样做的好处是：在一个集中的界面上去管理和监控RDS的备份操作；Amazon Web Services Backup 创建的备份对于 RDS 数据库管理员来说，只有恢复备份（Restore）的权限，而没有删除备份的权限，这样更安全。
以下举例说明如何设置一个 RDS 的备份计划，策略是连续备份保留 1 天，周期性快照备份每日备份一次，保留 7 天。首先，先制定备份计划表：
然后，在 Amazon Web Services Backup 中创建相应的备份计划、备份规则、并关联资源。如下：
在备份计划中关联资源 Tags=backup Value=PITRdaily1，并且在 RDS 数据库的 Tags 中设置 Tags=backup Value=PITRdaily1，从而将 RDS 数据库和备份计划关联起来。以下是 Amazon Web Services Backup 中执行备份计划后产生的备份数据：
最佳实践七：如何通过 Amazon Web Services Backup 防止“删库跑路”恶意者删除备份数据。某些恶意的数据删除行为会给企业造成无法弥补的损失，通过 Amazon Web Services Backup 的权限控制手段，可以防止恶意者删除备份数据，从而降低“删库跑路”事件带来的损失。通过以下的三个方法，即使恶意者拥有系统管理员的权限，也可以有效的保护备份数据。
- 通过 Amazon Web Services Backup 对数据进行集中备份，而不是由用户通过服务控制台进行备份。举例：普通用户在 EC2 控制台上对 Amazon Web Services Backup 创建的备份数据，只有查看权限，无删除权限。
- 对备份保管库（Backup Vault）进行权限控制，禁止对备份数据（Recovery Point）的删除操作。我们通过设置 Backup Vault的Access Policy 来禁止对备份数据的删除操作。注意：虽然Backup Vault是建在 S3 存储上的，但是这个S3桶并不在账号的 S3 界面可见，因此无法通过S3 桶策略来定义访问权限。只能通过 Backup Vault Access Policy。
- 选择 Edit Access policy。
- 选择 Edit Access policy。
- 在 Policy 编辑窗口中输入以下的策略。在策略中替换 statement ID ，例如Denydelete。在 aws:PrincipalArn 中替换 account id, user, role，唯有列出的这些 principal 具有删除备份数据的权限。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "statement ID",
"Effect": "Deny",
"Principal": "*",
"Action": "backup:DeleteRecoveryPoint",
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::112233445566:role/myrole",
"arn:aws:iam::112233445566:user/myuser",
"arn:aws:iam::112233445566:root"
]
}
}
}
]
}
- 将备份数据复制到另一个账号进行保护。即使恶意者获得了账号 A 的系统管理员身份，也无法删除复制到另一个账号B的备份数据。以下是跨账号备份的架构图：
|
A 账号 |
B 账号 |
|
普通用户 |
管理员用户 |
管理员用户 |
|
backup 集中备份 |
不可 |
可 |
n/a |
Backup Vault 禁止删除操作 |
不可 |
可 |
n/a |
备份数据复制到另一个账号保护 |
不可 |
不可 |
不可 |
在 Amazon Web Services 云上，许多大型企业已经普遍采用了多账号的公有云登录区（Landing Zone）设计。建立单独的共享服务账号、日志归档账号和安全管理账号，是多账号架构设计的一个重要理念。我建议企业客户在设计登录区时，单独规划一个备份账户作为企业整体多账号架构中的一环（例如文中的账户B)，用访问控制的手段防“删库跑路”。
小结
无论对于何种规模的 Amazon Web Services云用户，Amazon Web Services Backup 都是一个集中管理 Amazon Web Services 云资源备份的好帮手，尤其是它结合了跨账号跨区域的功能，更增加了在安全合规和数据容灾方面的价值。还犹豫什么呢？赶紧开始使用吧！
相关文章