【问题标题】:Restore a backup file on AWS RDS SQL Server from S3 bucket从 S3 存储桶恢复 AWS RDS SQL Server 上的备份文件
【发布时间】:2017-05-19 19:49:19
【问题描述】:

我能够使用以下命令从 AWS 上的 SQL Server 实例成功获取数据库备份到 S3 存储桶:

-- Backup databases - MyDB
exec msdb.dbo.rds_backup_database 
       @source_db_name='MyDB',
       @s3_arn_to_backup_to='arn:aws:s3:::mybucket/MyDB.bak',
       @overwrite_S3_backup_file=1;

使用以下命令将同一备份还原到同一区域内的不同 SQL Server 实例时,它不起作用:

    -- restore databases - MyDB
EXEC msdb.dbo.rds_restore_database 
        @restore_db_name='MyDB', 
        @s3_arn_to_restore_from='arn:aws:s3:::mybucket/MyDB.bak';

使用exec msdb.dbo.rds_task_status @db_name='MyDB'检查任务状态时出现以下错误

[2017-05-19 19:22:22.127] Aborted the task because of a task failure or a concurrent RESTORE_DB request.
[2017-05-19 19:22:22.150] Error making the request with Error Code Forbidden and Http Status Code Forbidden. No further error information was returned by the service.

到目前为止,我已经在多个数据库实例上完成了此备份和还原,从未见过这种错误。 S3 存储桶和需要恢复 .bak 文件的 SQL Server 实例位于同一区域,分配的选项组角色也具有在 S3 存储桶上设置的所有必需权限。以下是选项组角色策略:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::mybucket"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObjectMetaData",
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::mybucket/*"
             ]
        }
    ]
}

【问题讨论】:

    标签: sql-server amazon-web-services amazon-s3


    【解决方案1】:

    问题在于备份(.bak)文件,当它们没有正确传输或丢失一些元数据信息时,会出现此错误。最初,我使用命令将文件从一个 AWS 账户 (ap-northeast-1) 传输到不同区域的另一个 AWS 账户 (us-east-1)

    aws s3 sync s3://account1bucket s3://account2bucket --source-region ap-northeast-1
    

    但看起来这并没有正确地完成工作。现在,我已经从源 S3 存储桶手动下载文件并上传到目标 S3 存储桶,它现在开始工作了。

    这可能会解决使用 AWS CLI 传输存储桶内容的一些问题:https://github.com/aws/aws-cli/pull/1122

    【讨论】:

    • 我所要做的就是公开备份 db 文件,然后它就可以工作了。
    • 公开访问备份??听起来像灾难
    • 这是一个快速修复,后来我为存储桶添加了适当的权限
    • 必须有更好的解决方案,我现在也这样做了以获取我的备份,但必须向公众开放以编写备份然后删除权限似乎很可笑
    • 请不要公开您的备份文件!为我们解决的问题是,我们缺少源账户中 IAM 角色的所有权切换。看到这个link
    【解决方案2】:

    还有一点需要注意的是,SQL 备份文件名区分大小写。

    执行 msdb.dbo.rds_restore_database @restore_db_name='你的数据库名', @s3_arn_to_restore_from='arn:aws:s3:::/CASESENSITIVE_SQL_BACKUPNAME.BAK>';

    【讨论】:

      【解决方案3】:

      在一天中最开心的时候阅读帖子(包括这篇帖子),并仔细检查所有设置以发现问题是一个愚蠢的问题,我认为我会分享我的发现。

      当恢复过程无法访问或读取备份文件时,访问被拒绝是一个通用的错误消息。

      • 可以归结为存储桶/IAM 权限
      • 可能是错字(一些人已经发布了文件名 区分大小写)
      • 可能是文件损坏
      • 可能是文件/服务器不兼容,例如版本或作为 在我的情况下是一个压缩备份,其中选择的服务器没有 支持压缩

      【讨论】:

        【解决方案4】:

        我在帐户之间传输数据库实例时遇到了这个问题。我在 Destination 帐户中创建了一个 S3 存储桶,并为 Source 帐户授予了写入权限。

        当我转到 Source 数据库并将其备份到 S3 存储桶时,一切正常,但是当我尝试在 Destination 数据库中恢复该备份时,我得到错误:

        Error making request with Error Code Forbidden and Http Status Code Forbidden. No further error information was returned by the service.
        

        在找到这个帖子并看到有关权限的线索(包括使备份文件公开可读!)后,我发现即使备份已写入 Destination 帐户拥有的存储桶,备份那里的文件归 Source 帐户所有,而 Destination 帐户没有读取权限!这出乎我的意料。换句话说:

        存储桶的所有者可以将写入权限授予另一个帐户。然后,该帐户可以写入存储桶所有者可读的文件。

        现在回想起来,这完全有道理,虽然我没想到它是“默认”行为!

        我确信我可以通过考虑使用 AWS CLI 来修复权限,但在我的情况下,这样做要简单得多:

        1. 来源帐户中创建一个存储桶
        2. Destination 帐户授予读取权限
        3. Source 数据库备份到存储桶,为您提供存储桶中的一个文件,该文件均归 Source 帐户所有,但可由 Destination 帐户
        4. 将备份恢复到 Destination 帐户的数据库中

        【讨论】:

          【解决方案5】:

          从另一个帐户复制时使用 --acl bucket-owner-full-control。

          如果您已经复制了它,则必须在将对象添加到存储桶后授予访问权限:

          对象添加到存储桶后授予访问权限如果对象是 已经在另一个帐户的存储桶中,对象所有者可以授予 使用 put-object-acl 命令访问存储桶所有者:

          aws s3api put-object-acl --bucket destination_DOC-EXAMPLE-BUCKET --key keyname --acl bucket-owner-full-control
          

          来源:https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-owner-access/

          【讨论】:

            【解决方案6】:

            我所做的只是重新上传.bak 文件。显然,当我最初压缩它时,它遗漏了一些文件。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 2021-05-23
              • 1970-01-01
              • 2020-05-04
              • 1970-01-01
              • 2015-06-22
              • 2020-11-25
              • 2020-08-13
              相关资源
              最近更新 更多