任何形式的数据损坏都有可能导致数据的丢失，宕机。对于 DBA 来讲是一个不小的打击。云中托管的数据库无论从数据库的管理、高可用或灾难恢复上来讲都是 DBA 的一个很好的选择。如何利用传统的 SQL Server 的备份文件还原到 AWS 托管的 SQL Server 数据库是用户们普遍关心的问题。下面我将介绍：如何使用备份文件将 MS_SQL Server 还原数据库到 RDS SQL Server.
步骤：
1.创建一台管理主机
2.创建 RDS SQL Server
3.修改安全组和关联选项组
4.将已经备份的数据上传到 S3 上
5.创建并配置选项组
6.使用 SSMS 将 S3 上的.bak 还原到 RDS 上
步骤一：创建一台管理主机
创建 EC2 虚拟机做为管理主机，目的是出于安全角度考虑使用跳板机连接数据库，而不是将 SQL Server 的 Endpoint 暴露在公网上。
创建一台 EC2 虚拟机并安装 SQL Server Management Studio，不再赘述。
SSMS 工具下载地址：[top="1575.0625">步骤二：创建 RDS SQL Server
创建一台 SQL Server Standard Edition，
可以选择生产（Production）或开发／测试（Dev/Test）
生产环境也就是多可用区部署：
多可用区部署为数据库实例提供了更高的可用性、数据持久性和容错能力。在进行计划的数据维护或发生未计划的服务中断时，Amazon RDS 会自动故障转移到最新的辅助数据库实例。
开发和测试环境就是单实例，会有单点故障。
步骤三：修改安全组和关联选项组
修改 RDS 安全组，目的是让刚创建的管理主机与 RDS 建立连接，如下图：
在 RDS 的安全组中的 Source 修改成 EC2 的安全组 ID：
返回到管理主机上，使用 SSMS 测试连通性
连接成功
步骤四：将已经备份的数据上传到 S3 上
一般而言，如果你的文件大小达到 100MB，你应该考虑使用分段上传。使用 AWS 的 s3 cp 命令和 s3 sync 等命令可以自动对要上传的大文件分片，然后上传。如果你对命令不熟悉可以参考这篇 blog 中的 5. 使用 AWS CLI 的自动分段上传top="2793.0625">步骤五：创建并配置选项组
下面就是要创建和配置选项组，目的是添加 S3 的路径将 S3 上的.bak 文件还原到 RDS 上。
在创建选项组之前要确认一下 RDS 的 Engine 版本号，先记下来。
创建 Option Group
这里可能会问到，我的 RDS SQL server 对应 Engine 是什么？如下图：
我的 RDS 用的是 SQL Server Standard Edition 所用选择 sqlserver-se
根据前面 RDS instance 的截图，Major engine version 就是 14.00。
Add Option：
选择 Add option，选项如下图：
修改 RDS 实例并关联选项组
Change Option Group 为我们创建的 Option Group
modifying 这个状态大概会持续 30-60 秒，刷新一下
步骤六：使用 SSMS 将 S3 上的 bak 还原到 RDS 上
回到 SSMS 工具的 EC2 管理主机上执行还原脚本：
例 未加密
exec msdb.dbo.rds_restore_database@restore_db_name='database_name',@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name_and_extension';例 带加密
exec msdb.dbo.rds_restore_database@restore_db_name='database_name',@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name_and_extension',@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id';这里执行未加密的脚本：
exec msdb.dbo.rds_restore_database@restore_db_name='adventurerestore',@s3_arn_to_restore_from='arn:aws:s3:::sqlbakfilestest/AdventureWorks2017.bak';执行脚本，开始还原。
执行 exec msdb.dbo.rds_task_status;查看任务状态 complete 100 代表完成。
刷新数据库 还原的 adventurestore 已经建立好。
验证数据：
Trouble Shooting：
以下是使用本地备份和还原时可能会遇到的问题。
| 问题 | 问题排查建议 |
|---|---|
| Access Denied | 备份或恢复流程无法访问备份文件。这通常由类似于以下的问题导致：1. 引用不正确存储桶。使用不正确的格式引用存储桶。引用文件名但未使用 ARN。 2. 存储桶文件的权限不正确。例如，如果文件由正在尝试访问它的其他账户创建，请添加正确的权限。3.IAM 策略不正确或不完整。您的 IAM 角色必须包含所有的必要元素，例如，包括正确的版本。导入和导出 SQL Server 数据库中重点介绍了这些内容。 |
| BACKUP target="_blank">压缩备份文件。 | |
| Database <database_name> cannot be restored because there is already an existing target="_blank">还原数据库。 | |
| Please specify a bucket that is in the same region as RDS instance | 您无法备份到与您的 Amazon RDS 数据库实例不同的 AWS 区域中的 Amazon S3 存储桶或从中进行还原。您可以使用 Amazon S3 复制将备份文件复制到正确的区域。有关更多信息，请参阅 Amazon S3 文档中的跨区域复制。 |
| The specified bucket does not exist | 验证您使用正确格式为存储桶和文件提供了正确的 ARN。有关更多信息，请参阅使用本机备份和还原。 |
总结：
我们在迁移和还原的过程中就可以发现，AWS 对于服务的访问，数据库的连接，网络端口等等都会有非常详细的安全准则。数据库的安全是云中数据安全的非常重要的一部分。另外，对于数据库的高可用和安全，我们都可以通过这个博客了解。除此之外，Amazon Relational target="_blank">作者介绍：
李强
AWS 解决方案架构师，负责基于 AWS 的云计算方案架构的咨询和设计，同时致力于 AWS 云服务在国内的应用和推广，在物联网和微软的技术栈有着广泛的设计和实践经验。在加入 AWS 之前，曾在东芝中国负责系统开发和运维工作，在微软中国负责中小企业的技术咨询和方案设计工作。
原文链接：
