AWS Backup的优势功能和最佳实践

AWS Backup简介

AWS Backup是一项完全托管且免费的备份服务，可轻松高效地管理AWS资源的数据备份任务（包括 Amazon Elastic Compute Cloud (Amazon EC2) 实例、Amazon Elastic Block Store (Amazon EBS) 卷、Amazon Relational Database Service (RDS) 数据库（包括 Amazon Aurora 集群）、Amazon DynamoDB 表、Amazon Elastic File System (EFS)、Amazon FSx for Lustre、Amazon FSx for Windows File Server 和 AWS Storage Gateway 卷）。使用AWS Backup，用户可以跨组织（集成AWS Organizations服务）集中配置备份策略并监视AWS资源的备份活动。用户只需在AWS Backup控制台上单击几下，即可创建备份策略，以自动执行备份计划和数据保留管理。

AWS Backup对于任何规模的AWS用户来说，都是一个可以提升备份管理效率和备份安全合规性的工具。如果您想要一个完全托管的，基于策略的备份解决方案，以简化备份管理并使您能够满足业务和法规备份合规性要求，请立即开始使用AWS Backup。

AWS Backup的三大优势

AWS Backup的十大功能

AWS Backup的七个最佳实践

AWS Backup的三大优势

优势一：极大简化了AWS云资源的备份管理

• 自动化备份调度、保留管理和生命周期管理：AWS Backup解决了AWS云资源的备份管理分散在各个服务的控制台上、没有集中的备份管理界面的问题。它通过创建自动备份计划来管理备份的对象、频率、开始时间、备份目的地和备份数据保存期限。
• 在整个组织和多个帐户中进行管理：AWS Backup通过和AWS Organizations服务的集成，可以在Organization层面集中管理多个账户的备份。可以将同一个备份计划关联到多个账户或所有账户；可以在一个账户中监控所有账户的备份状况；可以将备份目的地设为另一个账号的的备份保管库。（注意：目前中国区暂不支持跨账号备份和跨账号备份管理的功能）
• 集中监控和警报：AWS Backup可通过AWS EventBridge来监控备份事件，例如在备份失败时及时发送报警。可通过CloudWatch和AWS控制台上的Dashboard来监控备份的各项指标，例如在过去24小时内已完成或失败的备份任务数量。可通过Cloudtrail来监控和审计备份的API操作，例如哪个用户在哪个时间执行了何种操作。可通过SNS来触发对备份相关事件的响应任务，例如在恢复作业结束给管理员发送一个邮件进行告知。
• 通过标记提高备份操作的一致性：当需要备份多个资源时（例如需要备份几十个EBS卷），使用标签（Tag）的方式来关联备份资源，是最简单最具扩展性的方法。例如在创建备份计划时，如果关联资源选择了标签为key: backup value: ebsdaily1，那么所有标签为key: backup value: ebsdaily1的EBS就会按照这个备份计划去备份。如果有新创建的EBS卷，只要打上同样的标签，就会被自动关联到此备份计划。

优势二：保障了安全和合规

• 跨服务集中执行备份策略和审核备份活动：管理员无需在各个受管服务的控制台上单独设置备份策略和执行按需备份，AWS Backup可以完成所有受管服务控制台上可执行的备份操作，例如，AWS Backup可支持RDS和Aurora的自动连续备份和时间点恢复。可以集中监控和审核所有的备份活动。可以在主账号上管理和监控所有子账号的备份作业。
• 对备份副本加密保护备份：AWS Backup会缺省对备份副本（跨区域或者跨账号或者同时跨区域跨帐号）通过AWS KMS进行数据加密。
• 通过 IAM 策略防止恶意或意外删除备份： 通过设置备份保管库（Backup Vault）的访问策略，可防止备份数据被恶意或意外删除。而且，通过AWS Backup备份的数据，只能通过AWS Backup的控制台或者API删除，例如，通过AWS Backup备份的EBS快照，无法通过EC2的控制台或者API删除。
• 实施跨区域备份，实现灾后恢复规划：AWS Backup可选择将备份数据复制到另一个区域的备份保管库，从而实现异地数据备份和灾难恢复。

优势三：节约了时间和成本

• 无需购买商业备份软件
• 节约了管理备份的时间，提高管理效率

AWS Backup的十大功能

企业客户在考察是否使用AWS Backup服务时，可能会考虑AWS Backup与传统的商业备份管理软件有何区别，例如Veritas NBU, Commvault等。以下是几个主要的区别：

1. AWS Backup是一个全托管服务，并不需要运行在EC2虚机上。而商业备份软件通常需要安装在一台或者多台EC2虚机上，日常运行会产生服务器成本。
2. AWS Backup是一个免费的服务，客户只需为实际使用的备份存储量付费（注意：EFS和DynamoDB在做恢复时会根据恢复数据量收取费用）。对比收费的商业备份管理软件，AWS Backup没有最低消费和软件使用费。
3. 商业备份管理软件通常支持文件级别的备份和恢复颗粒度，也能支持对数据库和应用的感知性，例如可支持Oracle数据库表级别的恢复、可支持Exchange的邮箱和邮件级的恢复，而AWS Backup仅支持EBS卷级别的恢复，对数据库仅支持整库级别的恢复，也不具备应用感知性。
4. AWS Backup不具备商业备份软件提供的高级功能，例如重复数据删除，数据压缩，多云多平台支持，应用感知等。而AWS Backup只是将EC2，RDS等云服务本身提供的备份功能集中在一个界面进行管理和调度，本身并不提供额外的功能。
5. 商业备份管理软件能实现混合云架构的备份、容灾一体化管理，例如私有云的数据备份到公有云，利用公有云的备份数据在私有云上实现恢复，灾难发生时利用备份数据在公有云上恢复应用等。而AWS Backup仅仅支持AWS上相关资源的备份和恢复。

AWS Backup的七个最佳实践

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

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

[AWS resource/Application]-[Region]-[Backup policy][Number]

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

Region：表示备份资源所在的AWS区域，例如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。这种简单的对应方式也体现了一个备份计划仅包含一个备份规则的好处。

最佳实践三：推荐使用资源标签（AWS Tag）方式来关联备份资源。AWS Backup支持两种方式在备份计划中关联备份资源，一种是Tag方式，另一种是Resource ID方式。Tag是AWS云资源运维管理中非常重要的一种方法，通过给需要备份的资源打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: [AWS 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

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

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

最佳实践六：RDS数据库的AWS Backup备份方案：连续备份和周期性快照备份相结合。

AWS RDS同时支持两种方式的备份，一种是自动备份（Automated Backup），对应任意时间点的恢复PITR（Point-in-Time Restore），一种是手工快照备份（Manually Snapshot），对应快照时间点的恢复（Snapshot Restore）。RDS的控制台上可以管理这两种备份方式。控制台的Automated Backup菜单上，可以查看数据库的可恢复时间点（Latest Restorable Time和Earliest Restorable Time）。

AWS Backup同时支持RDS的这两种备份方式（注意：暂不支持AWS Aurora的持续备份和PITR，只支持Aurora的快照备份）。AWS Backup中将RDS的自动备份称为连续备份（Continuous Backup）。连续备份的数据保留时间为1～35天，备份的颗粒度是1秒。周期性快照备份的最小频率是1小时，数据保留时间最长为100年。

有两个需要特别注意的地方。注意点一：AWS Backup的持续备份的优先级高于RDS的自动备份，如果在备份计划中开启了连续备份功能，则RDS的自动备份设置将失效，会使用AWS Backup的连续备份设置。RDS控制台上会提示自动备份已经被AWS Backup所接管，如下图：

注意点二：RDS数据库的自动备份功能必须处于开启状态，即自动备份的保留天数不能为0。否则在AWS Backup的备份计划中启用连续备份将不会起作用。

用户可以用两种方法来管理RDS的日常备份：方法一：在RDS控制台上设置自动备份，用AWS Backup管理周期性快照备份。方法二：在AWS Backup上同时管理RDS的自动备份和周期性快照备份。建议采用方法二，即在AWS Backup上同时管理RDS的自动备份和周期性快照备份，这样做的好处是：在一个集中的界面上去管理和监控RDS的备份操作；AWS Backup创建的备份对于RDS数据库管理员来说，只有恢复备份（Restore）的权限，而没有删除备份的权限，这样更安全。

以下举例说明如何设置一个RDS的备份计划，策略是连续备份保留1天，周期性快照备份每日备份一次，保留7天。首先，先制定备份计划表：

然后，在AWS Backup中创建相应的备份计划、备份规则、并关联资源。如下：

在备份计划中关联资源 Tags=backup Value=PITRdaily1，并且在RDS数据库的Tags中设置Tags=backup Value=PITRdaily1，从而将RDS数据库和备份计划关联起来。以下是AWS Backup中执行备份计划后产生的备份数据：

最佳实践七：如何通过AWS Backup 防止“删库跑路”恶意者删除备份数据。某些恶意的数据删除行为会给企业造成无法弥补的损失，通过AWS Backup的权限控制手段，可以防止恶意者删除备份数据，从而降低“删库跑路”事件带来的损失。通过以下的三个方法，即使恶意者拥有系统管理员的权限，也可以有效的保护备份数据。

（1）通过AWS Backup对数据进行集中备份，而不是由用户通过服务控制台进行备份。举例：普通用户在EC2控制台上对AWS Backup创建的备份数据，只有查看权限，无删除权限。

（2）对备份保管库（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"
                    ]
                }
            }
        }
    ]
}

（3）将备份数据复制到另一个账号进行保护。即使恶意者获得了账号A的系统管理员身份，也无法删除复制到另一个账号B的备份数据。以下是跨账号备份的架构图：

让我们总结一下以上三种方法，账户A的普通用户，账户A的管理员用户，账户B的管理员用户，是否可以删除全部的备份数据，达到“删库跑路”的目的。

在AWS云上，许多大型企业已经普遍采用了多账号的公有云登录区（Landing Zone）设计。建立单独的共享服务账号、日志归档账号和安全管理账号，是多账号架构设计的一个重要理念。我建议企业客户在设计登录区时，单独规划一个备份账户作为企业整体多账号架构中的一环（例如文中的账户B)，用访问控制的手段防“删库跑路”。关于Landing Zone的解决方案，用户可参考 https://aws.amazon.com/cn/solutions/implementations/aws-landing-zone/

小结

无论对于何种规模的AWS云用户，AWS Backup都是一个集中管理AWS云资源备份的好帮手，尤其是它结合了跨账号跨区域的功能，更增加了在安全合规和数据容灾方面的价值。还犹豫什么呢？赶紧开始使用吧！

参考链接：

《AWS Backup官方网站》

https://aws.amazon.com/cn/backup/

《AWS Backup开发人员指南》

https://docs.amazonaws.cn/aws-backup/latest/devguide/working-with-other-services.html#working-with-ec2

本篇作者