Блог

У нас есть группа опций, подключенная к одному из наших экземпляров SQL Server для резервного копирования в корзину S3. При попытке запустить резервное копирование с использованием rds_backup_database хранимой процедуры мы получаем следующие ошибки:

 [2021-03-18 20:20:22.260] Aborted the task because of a task failure or an overlap with your preferred backup window for RDS automated backup.
[2021-03-18 20:20:22.270] Task has been aborted
[2021-03-18 20:20:22.270] Access Denied
 

Все, что я прочитал, говорит о том, что это означает, что роль IAM, используемая для группы параметров резервного копирования и восстановления, не имеет надлежащих разрешений для корзины S3.

Тем не менее, кажется, что все настроено правильно. Вот конфигурация разрешений для этой роли.

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

Что касается окна резервного копирования, оно настроено на полчаса сразу после полуночи, поэтому мы не можем с этим конфликтовать.

Еще одна особенность заключается в том, что наш экземпляр RDS находится в регионе us-east-2a . Я не могу найти никакой информации о том, что us-east-2a есть. Вы не можете выбрать его, если у вас есть возможность выбора регионов. Наша корзина S3 us-east-2 включена, как и должно быть. Являются ли эти два региона одинаковыми, или это несоответствие является причиной сбоя при выполнении резервного копирования?

us-east-2a похоже, что это AZ, в котором находится ваша база данных:

регион по-прежнему us-east-2

на основе примера роли IAM для экспорта моментальных снимков базы данных:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html#USER_ExportSnapshot .Настройка роли

вы должны заявить arn:aws:s3:::your-s3-bucket в своем последнем заявлении,

От:

 {
  "Effect": "Allow",
  "Action": [
    "s3:GetObjectMetaData",
    "s3:GetObject",
    "s3:PutObject",
    "s3:ListMultipartUploadParts",
    "s3:AbortMultipartUpload"
  ],
  "Resource": [
    "arn:aws:s3:::sabmssqldevbackups/sabmssqldev/*"
  ]
}
 

Для:

 {
  "Effect": "Allow",
  "Action": [
    "s3:GetObjectMetaData",
    "s3:GetObject",
    "s3:PutObject",
    "s3:ListMultipartUploadParts",
    "s3:AbortMultipartUpload"
  ],
  "Resource": [
    "arn:aws:s3:::sabmssqldevbackups/sabmssqldev"
    "arn:aws:s3:::sabmssqldevbackups/sabmssqldev/*"
  ]
}
 

чтобы убедиться в том, что роль IAM работает, вы можете развернуть раздел AWS CLI в:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html#USER_ExportSnapshot .Экспорт

и запустите aws rds start-export-task команду, чтобы убедиться, что все работает:

 aws rds start-export-task 
    --export-task-identifier my_snapshot_export 
    --source-arn arn:aws:rds:AWS_Region:123456789012:snapshot:snapshot_name 
    --s3-bucket-name my_export_bucket 
    --iam-role-arn iam_role 
    --kms-key-id master_key
 

Это оказалось проблемой с ключом шифрования. Кто-то настроил наш экземпляр базы данных на использование ключа, управляемого AWS по умолчанию. Это создает проблему с постоянными разрешениями, которую можно устранить только путем шифрования с помощью ключа, управляемого клиентом. Поскольку вы не можете изменить ключи шифрования в существующем экземпляре базы данных, единственным решением является выполнение следующих действий:

• Создайте новый ключ, управляемый клиентом, в консоли KMS
• Сделайте снимок существующего экземпляра базы данных
• Восстановите этот моментальный снимок в новый экземпляр
• Примените управляемый клиентом ключ в качестве ключа шифрования
• Измените все существующие ссылки, чтобы они указывали на новый экземпляр БД
• Удалить исходный экземпляр

Гораздо больше работы, чем я надеялся.

Я думаю, вы пытаетесь выполнить резервное копирование на s3 в окне автоматического резервного копирования RDS, поэтому RDS уничтожит ваше собственное резервное копирование / восстановление SQL. Чтобы обойти эту проблему, никогда не запускайте собственные команды резервного копирования / восстановления SQL в запланированном окне резервного копирования RDS или не меняйте его на другое время: