云备份解决方案：Amazon Web Services Backup 的七个最佳实践

发布于: Aug 8, 2022

Amazon Web Services Backup 为您提供最佳的云备份解决方案，下面我们以七个实例来为您介绍 Amazon Web Services backup 的使用：

最佳实践一：一个备份计划（Backup Plan）仅包含一个备份规则（Backup Rule）并且只备份一种备份资源(Resource)。这样做的好处是容易从 Backup Plan 的命名上直接理解备份的内容，并且便于管理，对一种资源的备份计划的修改不会影响其他的资源。例如，备份计划“ebs-cn-north-1-daily1”只包含一个每日备份的备份规则，且只备份 ebs 卷这一种资源。

最佳实践二：一个规范且容易理解的备份计划和备份规则的命名规则，对于方便日常的备份管理非常重要。以下是一个笔者推荐的命名规则：

[Amazon Web Services resource/Application]-[Region]-[Backup
policy][Number]

Amazon Web Services resource/Application：表示备份的 Amazon Web Services 资源类型或者应用名称，例如 ec2, ebs，splunk 等。

Region：表示备份资源所在的 Amazon Web Services 区域，例如 cn-north-1，cn-northwest-1 等。

Backup policy：表示备份的策略，例如 daily 或者 weekly。如果需要复制备份到另一个 Region，就在后面加上 rcp 代表 remote copy。

Number：这个数字用来进一步区分不同的备份计划，例如 1，2 等。

以下是备份计划的一些命名举例：

ebs-cn-north-1-daily1 表示对于 ebs 卷的每日备份

ebs-cn-north-1-weekly1 表示对于 ebs 卷的每周备份

ebs-cn-north-1-dailyrcp1 表示对于 ebs 卷的每日备份并且需要复制到另一个region

splunk-cn-north-1-daily1 表示对于 splunk 这个应用的每日备份

rds-cn-north-1-weekly1 表示对于rds的每周备份

efs-cn-north-1-weekly1 表示对于efs的每周备份

对于备份规则（Backup Rules）的命名，由于一个备份计划只包含一个备份规则，所以最简单的方式就是备份规则的命名和备份计划完全相同。例如以ebs-cn-north-1-daily1命名的备份计划对应的备份规则命名也是ebs-cn-north-1-daily1。这种简单的对应方式也体现了一个备份计划仅包含一个备份规则的好处。

最佳实践三：推荐使用资源标签（Amazon Web Services Tag）方式来关联备份资源。Amazon Web Services Backup 支持两种方式在备份计划中关联备份资源，一种是 Tag 方式，另一种是Resource ID方式。Tag 是 Amazon Web Services 云资源运维管理中非常重要的一种方法，通过给需要备份的资源打Tag，避免在添加、删除和修改资源的备份策略时直接去修改备份计划，而只需要修改资源的 Tag，这种方式更简单也更灵活。

举个例子，备份计划 ebs-cn-north-1-daily1 关联的资源 Tag 为 key: backup value: ebsdaily1，备份计划 ebs-cn-north-1-weekly1 关联的资源 Tag 为 key: backup value: ebsweekly1。当新创建一个 ebs 卷时，只需要将 Tag Key: backup 的 value 设置为 ebsdaily1，就能将这个 ebs 卷添加到每日备份的计划。如果修改 value 的设置为 ebsweekly1，就能将这个 ebs 卷添加到每周备份的计划。以下是Tag的命名规范示例：

Tag Key: backup

Tag Value: [Amazon Web Services
resource/Application][Backup policy][Number]

Example:

key: backup value: ebsdaily1

key: backup value: ebsweekly1

key: backup value: ebsdailyrcp1

key: backup value: splunkdaily1

key: backup value: rdsweekly1

key: backup value: efsweekly1

最佳实践四：在开始设置Amazon Web Services Backup之前，需要对整体的备份方案做一个全面的规划，包括各种资源的备份策略（Backup Schedule）和过期策略（Expire Schedule）。同时，这样的一个备份计划表也便于管理。以下是一个示例：

最佳实践五：对于一次性备份需求的管理。一次性备份（One-time
backup）或者称为（On-demand backup）是指临时性的一些备份需求。资源的拥有者需要提备份申请给运维团队来操作备份，提申请时需要指定备份资源和保留日期。以下是一个申请的示例：

最佳实践六：RDS 数据库的 Amazon Web Services 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。

在 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的普通用户，账户 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 云资源备份的好帮手，尤其是它结合了跨账号跨区域的功能，更增加了在安全合规和数据容灾方面的价值。还犹豫什么呢？赶紧开始使用吧！

相关文章