本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
连续备份和时间点故障恢复(PITR)
对于某些资源,除了快照备份外,还 AWS Backup 支持持续备份和时间点恢复 (PITR)。
通过持续备份,您可以将 AWS Backup支持的资源恢复到您选择的特定时间,精度在 1 秒以内(最多回溯至 35 天)。连续备份的工作原理是,首先创建资源的完整备份,然后不断备份资源的事务日志。PITR 的工作原理是,访问完整备份,然后将事务日志重放到您要求 AWS Backup 恢复的时间。
或者,可以每小时进行一次快照备份。快照备份最多可存储 100 年。可以复制快照进行完整备份或增量备份。
由于连续备份和快照备份具有不同的优势,因此建议您同时使用连续备份和快照备份规则来保护您的资源。
按需备份会立即开始备份您的资源。如果您希望在备份计划中定义的计划时间以外的时间创建备份,则可以选择按需备份。例如,可以随时使用按需备份来测试备份和功能。
按需备份不能与 PITR 一起使用,因为按需备份会将资源保留在创建备份时其所处的状态,而 PITR 使用连续备份来记录一段时间内的变化。
在 AWS Backup 使用 AWS Backup 控制台或 API 创建备份计划时,您可以选择对支持的资源进行持续备份。连续备份计划会创建一个连续恢复点,每当作业运行时就会更新该恢复点。
Point-in-time 恢复注意事项
了解针对时间点故障恢复的以下注意事项:
-
自动回退到快照 - 如果 AWS Backup 无法执行连续备份,则会尝试执行快照备份。
-
不支持按需持续备份 — AWS Backup 不支持按需持续备份,因为按需备份记录一个时间点,而连续备份记录会在一段时间内发生变化。
-
不支持转换到冷存储 - 连续备份不支持转换到冷存储,因为转换到冷存储至少需要 90 天的转换期,而连续备份的最大保留期为 35 天。
-
恢复最近的活动 — Amazon RDS 活动允许恢复至最近 5 分钟的活动;Aurora 允许恢复至最近的 5 分钟活动,如所示
LatestRestorableTime(通常少于 5 分钟);Amazon S3 允许恢复到最近 15 分钟的活动。
重要
单个资源只能包含一个连续备份。请展开下文,了解更多详细信息和最佳实践。
每个资源(例如 Amazon S3 存储桶或 Amazon RDS 数据库)只能包含一个连续备份(恢复点);额外的连续备份是冗余的。当多个备份策略、计划或规则指示 AWS Backup 为同一资源创建多个连续备份时,以下过程适用:
-
如果多个规则指定一个保管库中应有多个连续备份,则 AWS Backup 遵循保留期(生命周期)最长的规则,忽略其他规则。
-
如果多个规则指定多个连续备份应位于多个保管库中,则根据处理的第一条规则 AWS Backup 创建一个连续备份。后续每条为已包含连续备份的资源指定连续备份的规则都将导致快照(定期)备份。
出现重复的连续备份计划时,在连续恢复点之后创建的快照备份的状态可能显示为 Completed with issues。此恢复点的详细信息将显示类似于 “Enabling continuous backup failed, because of the following error: PITR already
configured in backup plan: [ARN]” 的错误。此错误表示已配置至少一个连续备份(用于与包含错误的恢复点不同的恢复点)。只要第一个连续备份(恢复点)的状态为 COMPLETED,就可以将其用于时间点恢复(PITR)。
为防止创建存在问题(和错误消息)的意外快照,请查看组织备份策略。如有必要,调整为同一资源创建多个连续备份的备份计划和策略。
在您进行调整,仅对资源进行一次连续备份后,快照备份将根据创建它们的计划的指定生命周期进行保留,然后它们将变为 EXPIRED 并删除。连续备份及其时间点故障恢复能力将根据创建它的规则进行维护。
提供连续备份和 PITR 支持的服务
AWS Backup 支持以下服务和应用程序的持续备份和时间点恢复:
Amazon S3
要为 S3 备份启用 PITR,需要将连续备份设置为备份计划的一部分。
虽然源存储桶的原始备份可能已激活 PITR,但跨区域或跨账户目的地副本不具有 PITR,因此从这些副本还原将还原到它们的创建时间(这些副本将是快照副本),而不是还原到指定的时间点。
AWS Backup for S3 依赖于通过亚马逊接收 S3 事件 EventBridge。如果在 S3 存储桶通知设置中禁用此设置,则在关闭此设置的情况下,将停止对这些存储桶的连续备份。有关更多信息,请参阅 Amazon EventBridge 对 S3 持续备份的依赖。
禁用 AWS Backup的 Amazon EventBridge 规则也将导致您的持续备份停止。如果您有具有持续备份规则的有效备份计划,则当该规则重新触发时, AWS Backup 将重新创建 Amazon EventBridge 规则,并创建新的持续备份。
RDS
AWS Backup 支持对原生 Amazon RDS 服务支持的所有 Amazon RDS 实例和 Aurora 进行持续备份和时间点恢复。 AWS Backup 不支持 Amazon RDS Multi-AZ 集群的持续备份或时间点恢复。
备份计划:当您为 Amazon RDS 实例启用持续备份时 AWS Backup, AWS Backup 将接管 Amazon RDS 自动备份窗口(锚定时间点恢复的本地每日快照)。 AWS Backup 将此自动备份窗口放在 Amazon RDS 维护窗口附近,以防止冲突。在 AWS Backup 管理持续备份时,您无法直接配置自动备份窗口,但您可以通过调整 Amazon RDS 维护窗口来影响其位置。自动备份窗口会在下一个备份周期重新定位。即使备份计划中的快照备份频率不是每天一次,RDS 也会每天拍摄一次快照。
注意
AWS Backup 不修改或管理 Amazon RDS 维护窗口。维护时段仍在您的控制之下,可以通过 Amazon RDS 设置进行调整。由备份计划中的快照规则启动的备份作业按照您定义的时间表运行,如果它们与维护时段重叠,仍可能失败。如果发生这种情况,您将收到类似于 “备份任务无法启动,因为它在 RDS 实例中配置的每周维护窗口之内或距离太近” 的错误。为避免此错误,请在配置的 Amazon RDS 维护时段之外安排快照备份规则。
设置:将 AWS Backup 持续备份规则应用于 Amazon RDS 实例后,您无法在 Amazon RDS 中创建或修改持续备份设置。必须通过 AWS Backup 控制台或 AWS Backup CLI 进行修改。当您首次开启自动备份时,如果将数据库实例的备份保留期从 0 更改为非零值,则会发生中断。在维护时段内计划此项变更以最大限度地减少影响。有关启用自动备份的更多信息,请参阅 Amazon RDS 用户指南中的启用自动备份。
将 Amazon RDS 实例的连续备份控制权转移回 Amazon RDS:
Amazon RDS 连续备份所需的 IAM 权限
-
AWS Backup 要使用为您的 Amazon RDS 数据库配置持续备份,请验证备份计划配置定义的 IAM 角色中是否
rds:ModifyDBInstance存在 API 权限。要还原 Amazon RDS 连续备份,您必须向为还原任务提交的 IAM 角色添加权限rds:RestoreDBInstanceToPointInTime。您可以使用AWS Backup default service role执行备份和还原。 -
要描述可用于时间点恢复的时间范围, AWS Backup 请致电。
rds:DescribeDBInstanceAutomatedBackups在 AWS Backup 控制台中,您必须拥有 AWS Identity and Access Management (IAM) 托管策略中的rds:DescribeDBInstanceAutomatedBackupsAPI 权限。您可以使用AWSBackupFullAccess或AWSBackupOperatorAccess托管式策略。这两个策略都具有所有必需的权限。有关更多信息,请参阅托管策略。
保留期:当您更改 PITR 保留期限时, AWS Backup ModifyDBInstance请致电申请该更改。
首次在 Amazon RDS 实例上 AWS Backup 启用 PITR(将保留期从 0 更改为非零值)时,该操作计划在数据库的下一个维护窗口内进行,以防止意外停机。
场景:
-
First-time PITR 启用:当首次在 Amazon RDS 实例上启用 PITR 时(无论它是由实例管理 AWS Backup 还是直接配置),更改都会排队等待下一个维护窗口。 AWS Backup 自动创建快照备份以保持覆盖范围,直到 PITR 变为活动状态。
-
PITR 保留期更改: Non-zero 非零保留期更改立即生效,无需重启。
-
PITR 禁用:计划在下一个维护窗口中将保留期从非零更改为零。
过渡期间的备份覆盖范围:
-
快照备份可在等待维护时段提供保护
-
启用 PITR 后,当备份作业运行时,持续恢复点将变为可用
-
过渡期间备份保护不存在间隙
-
恢复粒度可能仅限于快照间隔,直到 PITR 完全处于活动状态
注意:停止 RDS 实例将删除待处理的更改。PITR 配置更改将在下一次备份任务中重新启动,并在随后的维护时段内应用。
Amazon RDS 连续备份的副本:
-
创建 Amazon RDS 持续备份的副本 — 您无法创建 Amazon RDS 持续备份的副本,因为 AWS Backup 对于 Amazon RDS,不允许复制交易日志。相反, AWS Backup 创建快照并按照备份计划中指定的频率进行复制。
还原:您可以使用 AWS Backup 或 Amazon RDS 执行时间点还原。有关 AWS Backup 控制台说明,请参阅恢复 Amazon RDS 数据库。有关 Amazon RDS 说明,请参阅《Amazon RDS 用户指南》中的将数据库实例还原到指定时间。
提示
设置为 Always On 的多可用区数据库实例不应将备份保留期设置为 0。如果出现错误,请disassociate-recovery-point改用 AWS CLI 命令delete-recovery-point,然后在 Amazon RDS 设置中将保留设置更改为 1。
有关使用 Amazon RDS 的一般信息,请参阅 Amazon RDS 用户指南。
RDS 和 Aurora PITR 恢复的 CLI 示例
以下示例演示如何使用带有元数据参数的 AWS Backup CLI 将 RDS 和 Aurora 数据库恢复到某个时间点。
示例:使用元数据将 RDS 数据库恢复到某个时间点
aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:1EB3B5E7-9EB0-435A-A80B-108B488B0D45 \ --metadata '{"DBInstanceIdentifier":"restored-db-instance","Engine":"mysql","UseLatestRestorableTime":"false","RestoreTime":"2024-01-15T10:30:00Z"}' \ --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \ --resource-type RDS \ --copy-source-tags-to-restored-resource
示例:将 Aurora 集群恢复到某个时间点
aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:2FC4C6F8-0FC1-546B-B91C-209C599C1D56 \ --metadata '{"DBClusterIdentifier":"restored-aurora-cluster","Engine":"aurora-mysql","UseLatestRestorableTime":"true"}' \ --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \ --resource-type Aurora \ --copy-source-tags-to-restored-resource
RDS PITR 恢复的元数据参数
RDS 和 Aurora PITR 恢复支持以下元数据参数:
-
DBInstanceIdentifier(RDS) 或 DBClusterIdentifier (Aurora)-必填项。还原的数据库的名称。
-
引擎 -必需。数据库引擎(例如 mysql、postgres、aurora-mysql、aurora-postgresql)。
-
UseLatestRestorableTime – 可选。设置为 “true” 以恢复到最新的可恢复时间,或设置为 “false” 以指定。 RestoreTime
-
RestoreTime – 可选。要恢复的日期和时间(ISO 8601 格式)。如果 UseLatestRestorableTime 为 “假”,则为必填项。
将标签复制到还原的资源
使用该--copy-source-tags-to-restored-resource标志将标签从源数据库复制到还原的数据库。这可确保保留基于标签的访问控制和成本分配标签。
有关 RDS PITR 还原参数的完整详细信息,请参阅:
-
RestoreDBInstanceToPointInTime在 Amazon RDS API 参考中
-
RestoreDBClusterToPointInTime在 Amazon RDS API 参考中
Aurora
要启用对您的 Aurora 资源的连续备份,请参阅本页第一部分中的步骤。
将 Aurora 集群还原到某个时间点的过程是还原 Aurora 集群快照的步骤的变体。
当您进行时间点还原时,控制台会显示还原时间部分。请参阅本页下方使用连续备份中的还原连续备份。
重要
受 AWS Backup 文件库锁保护的保管库支持 Aurora 持续备份,并且在恢复点上强制执行保管库的最小和最大保留设置。但是,Aurora 持续备份不支持逻辑气隙保管库功能。要在 Aurora 中使用逻辑上的气隙保管库,请改用定期快照备份。
Aurora 持续备份的恢复点目标 (RPO) 通常少于 5 分钟,因为 Aurora 会在后台持续将数据复制到 Amazon S3。使用该LatestRestorableTime值来确定可以恢复到的最新点。
保留期和备份窗口:当您启用或更改 Aurora 集群的持续备份设置时,会 AWS Backup 调用ModifyDBCluster以应用这些更改。这可以修改集群的PreferredBackupWindow。如果您还有其他配置更新等待下一个维护窗口,则启用持续备份也可以立即应用这些待处理的更改。
注意
AWS Backup 要使用为 Aurora 集群配置持续备份,请验证备份计划配置定义的 IAM 角色中是否rds:ModifyDBCluster存在 API 权限。
Amazon EC2 实例上的 SAP HANA
您可以进行连续备份,它可以与时间点还原 (PITR) 一起使用(请注意,按需备份以创建备份时所处的状态保存资源;而 PITR 使用的是连续备份,它记录一段时间内的变化)。
使用连续备份,可以还原 EC2 实例上的 SAP HANA 数据库,方法是将其倒回您选择的特定时间,精确到 1 秒(最多回溯 35 天)。连续备份的工作原理是,首先创建资源的完整备份,然后不断备份资源的事务日志。PITR 还原的工作原理是访问您的完整备份并将事务日志重播到您要求恢复的时间。 AWS Backup
在 AWS Backup 使用 AWS Backup 控制台或 API 创建备份计划时,您可以选择持续备份。
使用控制台启用连续备份
登录 AWS 管理控制台,然后在上打开 AWS Backup 控制台https://console.aws.amazon.com/backup
。 -
在导航窗格中,选择备份计划,然后选择创建备份计划。
-
在备份计划下,选择添加备份计划。
-
在备份规则配置部分,选择为支持的资源启用连续备份。
对 SAP HANA 数据库备份禁用 PITR(时间点还原)后,会将日志继续发送到 AWS Backup
中,直到恢复点到期(状态等于 EXPIRED))。您可以更改到 SAP HANA 中的替代日志备份位置,以停止向 AWS Backup传输日志。
状态为的持续恢复点STOPPED表示连续恢复点已中断;也就是说,从 SAP HANA 传输到 AWS Backup 显示数据库增量更改的日志存在间隙。在此时间范围间隙内出现的恢复点状态为 STOPPED.。
有关在连续备份(恢复点)的还原作业期间可能遇到的问题,请参阅本指南的 SAP HANA 还原故障排除部分。