我们的许多客户将 Amazon Relational Database Service (Amazon RDS) for SQL Server 用于其大型任务关键型 SQL Server 数据库。客户要求提供最佳解决方案来保护适用于 SQL Server 的 Amazon RDS 上的大型数据库,以帮助他们满足恢复点目标 (RPO)(可接受的最大数据丢失)和恢复时间目标 (RTO)(服务中断和服务恢复之间的最大可接受延迟)的要求。
数据库管理员的职责之一是保护公司的数据。Amazon RDS for SQL Server 具有多个选项来帮助您备份和还原数据。在使用适用于 SQL Server 的 Amazon RDS 为大型数据库制定备份策略时,应考虑以下事项:
- 数据库的大小是多少?
- 您想在 RDS 数据库实例上还原单个数据库还是多个数据库?
- 备份和恢复策略是否需要区域内和跨区域保护?
通常,您可以从多种策略中进行选择,以保护适用于 SQL Server 的 Amazon RDS 上的数据,包括使用自动快照或手动快照、AWS 备份、本机备份和还原或组合使用。但是,管理大型 SQL Server 数据库(超过 5 TB)可能包含数 TB 的信息,并且可能很麻烦。
在这篇文章中,我们将引导您完成托管在 Amazon RDS for SQL Server 上的大型 SQL Server 数据库的两个备份和还原选项。
本机备份和还原方法
Amazon RDS 支持 SQL Server 数据库的本机备份和还原。您可以创建 RDS for SQL Server 数据库的完整备份,并将该文件存储在 Amazon Simple Storage Service (Amazon S3) 中。然后,您可以将备份文件还原到适用于 SQL Server 数据库的现有 RDS 实例。您还可以将此备份文件还原到本地服务器或适用于 SQL Server 数据库的其他 RDS 实例。您可以通过添加 SQL_Server_Backup_Restore 选项组为 Amazon RDS for SQL Server 启用本机 SQL 备份和还原。
下图说明了本机备份和还原解决方案的体系结构。
先决条件
在开始之前,需要满足以下先决条件:
- 适用于 SQL Server 的 RDS 实例
- 具有 Amazon RDS for SQL Server 权限的 S3 存储桶
将数据库备份到多个备份文件
使用以下命令对 RDS for SQL Server 数据库执行本机备份:
exec msdb.dbo.rds_backup_database @source_db_name='database_name', @s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name.extension', [@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'], [@overwrite_s3_backup_file=0|1], [@type='DIFFERENTIAL|FULL'], [@number_of_files=n];
@number_of_files指示备份划分(分块)的文件数。最大数量为 10。
完整备份和差异备份都支持多文件备份。如果输入值 1 或省略该参数,则会创建单个备份文件。
生成大型数据库的备份时,建议在多个文件中生成备份。此过程可减少生成备份的时间。如果您的业务需求是从 Amazon S3 下载大型数据库的备份,则下载多个备份文件比下载一个大型备份文件更快。
以下脚本使用 gp2 存储和 r5b.4xlarge 实例将我们的示例 RDS for SQL Server 数据库 (10 TB) 备份到单个备份文件:
exec msdb.dbo.rds_backup_database @source_db_name='TPCC', @s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBSingleFile.bak', @overwrite_s3_backup_file=1;
由于我们使用单个备份文件,因此备份失败并显示以下错误,因为单个 Amazon S3 对象的大小范围从最小 0 字节到最大 5TB 不等。
“[2022-09-09 13:26:22.083] 任务执行已开始。[2022-09-09 13:26:22.300]由于任务失败或与 RDS 自动备份的首选备份窗口重叠,任务已中止。[2022-09-09 13:26:22.303]任务已中止 [2022-09-09 13:26:22.310] 无法生成大于 524288000 字节的 S3 区块以上传到 S3。
为了克服此限制,我们提供了一种将数据库备份到多个文件中的不同方法。此方法也是帮助降低 RPO 和 RTO 的首选方法。
我们可以对四个备份文件运行相同的脚本:
exec msdb.dbo.rds_backup_database @source_db_name='TPCC', @s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBMultiFile*.bak', @number_of_files=4;
如以下屏幕截图所示,备份已成功完成。
我们对不同的数据库大小进行了类似的测试。
例如,使用以下命令为 5 TB 数据库执行单个文件备份。
exec msdb.dbo.rds_backup_database @source_db_name='TPCC', @s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak', @overwrite_s3_backup_file=1;
以下屏幕截图显示了我们的结果。使用一个文件在602分钟内完成5TB数据库的备份。
从多个备份文件还原数据库
可以将简单脚本作为过程创建和编译,并将其用作 T-SQL 工具,用于将大型数据库备份文件拆分为多个小文件。
请注意,为了从备份文件还原数据库,还原数据库命令需要所有备份文件。
该过程适用于 SQL Server 版本 2014 及更高版本。
使用以下还原命令使用多个文件备份还原 10 TB 数据库。星号 (*) 可以位于 S3 ARN file_name部分的任何位置。星号将在生成的文件中替换为一系列字母数字字符串。
exec msdb.dbo.rds_restore_database
@restore_db_name='TPCC',
@s3_arn_to_restore_from='arn:aws:s3:::sqlbackup-tpcc/backup/10TB/TPCC10TBbackup*';以下屏幕截图显示还原在 470 分钟内成功完成。
使用以下还原命令通过单个数据库文件备份还原 5 TB 数据库:
exec msdb.dbo.rds_restore_database @restore_db_name='TPCC', @s3_arn_to_restore_from='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak';
以下屏幕截图显示还原在 1008 分钟内成功完成。
测试结果
下表总结了在具有 r5b.4xlarge 实例的 Amazon RDS for SQL Server 上使用不同数据库大小执行的测试。我们观察到,与单个文件相比,使用四个多文件可以缩短备份和还原 1TB 和 5TB 数据库大小所需的时间。由于单个文件中可以上传到 S3 的最大对象是 5TB,因此我们目前无法在单个文件中备份和还原大于 5TB(例如 10TB)的数据库大小。
| 测试实例 | 活动类型 | 单个文件(分钟) | 四个文件(分钟) | 性能改进 (%) |
| 1 TB(GP2,分配 3 TB 存储) | 备份 | 151 | 56 | 62.91 |
| 1 TB(GP2,分配 3 TB 存储) | 恢复 | 200 | 57 | 71.50 |
| 1 TB (i01-40000 IOPS) | 备份 | 140 | 52 | 62.86 |
| 1 TB (i01-40000 IOPS) | 恢复 | 154 | 54 | 64.93 |
| 5TB(GP2,分配 10 TB 存储空间) | 备份 | 602 | 235 | 60.96 |
| 5TB(GP2,分配 10 TB 存储空间) | 恢复 | 1008 | 291 | 71.23 |
| 5 TB (io1-40000 IOPS) | 备份 | 601 | 212 | 64.73 |
| 5 TB (io1-40000 IOPS) | 恢复 | 991 | 208 | 79.01 |
| 10TB(已分配 gp2,16TB 存储空间) | 备份 | 不适用 | 663 | 不适用 |
| 10TB(已分配 gp2,16TB 存储空间) | 恢复 | 不适用 | 681 | 不适用 |
| 10 TB (io1-40000 IOPS) | 备份 | 不适用 | 590 | 不适用 |
| 10 TB (io1-40000 IOPS) | 恢复 | 不适用 | 470 | 不适用 |
我们执行了类似的测试,将备份文件的数量增加到八个,以查看影响:
exec msdb.dbo.rds_backup_database @source_db_name='TPCC', @s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB8files*', @number_of_files=8;
对于此特定实例,结果显示,与使用四个具有我们测试的实例大小的备份文件相比,时间没有差异。
最佳文件数取决于实例大小。例如,如果实例有 32vCPU,则将其拆分为 8 个文件比拆分 4 个文件更快。
快照方法
Amazon RDS for SQL Server 除了允许自动备份之外,还允许您拍摄手动快照。这些是数据库实例的存储卷快照,用于备份整个数据库实例,而不仅仅是单个数据库。快照备份所需的时间取决于数据库实例的大小和类。在此测试中,我们使用了一个 r5b.4xlarge 实例。
我们注意到的一个有趣的观察结果是,对于分配了 16 TB 存储的 10 TB 数据库,初始手动快照(备份)大约需要 11 个小时。但是从快照恢复只用了 23 分钟。这有助于减少数据库的 RTO。
数据库实例的第一个快照包含完整数据库实例的数据。同一数据库实例的后续快照是增量快照,这意味着仅保存最近快照后更改的数据。
在初始手动快照之后,下一个快照仅用了 5 分钟,还原时间为 20 分钟。快照还原方法还可以帮助您降低其他数据库的 RPO 和 RTO。
还原的数据库实例在其状态可用时立即使用。数据库实例继续在后台加载数据。这称为延迟加载。为了帮助减轻延迟加载对需要快速访问的表的影响,可以执行涉及全表扫描的操作,例如。这允许 RDS for SQL Server 实例从 Amazon S3 下载备份的表数据。SELECT *
下表总结了我们在初始快照备份和还原方面的发现。
| 测试实例 | 活动类型 | 持续时间(分钟) |
| 1 TB(GP2,分配 3 TB 存储) | Snapshot_Backup | 109 |
| 1 TB(GP2,分配 3 TB 存储) | Snapshot_Restore | 16 |
| 5 TB(GP2,分配 10 TB 存储) | Snapshot_Backup | 480 |
| 5 TB(GP2,分配 10 TB 存储) | Snapshot_Restore | 20 |
| 10 TB(GP2,分配 16 TB 存储) | Snapshot_Backup | 635 |
| 10 TB(GP2,分配 16 TB 存储) | Snapshot_Restore | 23 |
收拾
使用完本文中的资源后,请清理 AWS 资源以避免产生不必要的费用。具体而言,请从此测试中使用的 S3 存储桶中删除适用于 SQL Server 的 RDS 实例和所有对象。
结论
在这篇文章中,我们介绍了两种方法,介绍如何以最小的 RTO 和 RPO 备份和还原托管在 Amazon RDS for SQL Server 上的大型 SQL Server 数据库。首先,我们演示了如何使用 SQL Server 本机备份优化备份和还原到多个文件。与备份到单个文件相比,此方法可以帮助您加快备份时间和还原时间。然后,我们向您展示了手动快照方法以及我们从性能测试结果中得出的结果。
原文作者:Yogi Barot 和 Vikas Babu Gali
原文标题:Backup and restore strategies for large databases on Amazon RDS for SQL Server Amazon RDS for SQL Server 上大型数据库的备份和还原策略
原文地址:https://aws.amazon.com/cn/blogs/database/backup-and-restore-strategies-for-large-databases-on-amazon-rds-for-sql-server/










