Резервное копирование и восстановление

Backup and Restore — это самая простая и экономичная стратегия аварийного восстановления. Вы регулярно создаёте резервные копии данных и инфраструктуры, храните их в надёжном месте (обычно в S3 в другом регионе), а при аварии восстанавливаете данные из этих копий. Несмотря на низкую стоимость обслуживания, эта стратегия обеспечивает самое длительное RTO (часы) и потенциально значительное RPO (время с момента последнего резервного копирования). Она подходит для некритичных рабочих нагрузок, для которых допустим простой в несколько часов.

AWS Backup — это полностью управляемый сервис, который централизует и автоматизирует защиту данных в сервисах AWS. Он поддерживает тома EBS, базы данных RDS, таблицы DynamoDB, файловые системы EFS, FSx, экземпляры EC2, кластеры Aurora и S3. Вы определяете планы резервного копирования с расписаниями, сроками хранения и хранилищами назначения. AWS Backup применяет политики резервного копирования к нескольким аккаунтам через AWS Organizations, что делает его основным сервисом для управления резервным копированием в компаниях.

Amazon RDS автоматически создаёт ежедневные снимки и сохраняет журналы транзакций, чтобы обеспечить восстановление на определённый момент времени (PITR). Вы можете восстановить базу данных на любую секунду в пределах периода хранения резервных копий (от 1 до 35 дней). Автоматические резервные копии хранятся в S3 (AWS управляет ими, и они не отображаются в консоли S3). Для межрегионального DR используйте консоль или CLI, чтобы скопировать снимки базы данных в другой регион — копию можно использовать для запуска нового экземпляра RDS во время аварии.

Межрегиональная репликация S3 (CRR) автоматически реплицирует новые объекты из исходного бакета в целевой бакет в другом регионе. Для резервного копирования настройте задания резервного копирования так, чтобы они записывали данные в бакет S3 с включённым CRR, — резервные копии автоматически копируются в регион DR в течение нескольких минут. Включите versioning в обоих бакетах (это требуется для CRR), чтобы сохранять старые версии резервных копий. Объедините эту возможность с блокировкой объектов S3, чтобы сделать резервные копии неизменяемыми и защитить их от программ-вымогателей.

Чтобы обеспечить восстановление EC2 в регионе DR, заранее создайте образы машин Amazon (AMI) на основе рабочих экземпляров EC2 и скопируйте их в регион DR. AMI содержат корневой том, конфигурацию экземпляра и, при необходимости, тома с данными. В случае аварии запустите новые экземпляры EC2 из AMI региона DR и подключите восстановленные тома EBS. Автоматизируйте создание AMI с помощью типа ресурса AWS Backup EC2 или EC2 Image Builder для конвейеров эталонных образов.

DynamoDB предлагает два механизма резервного копирования. Резервные копии по требованию немедленно создают полную копию без влияния на производительность — их можно хранить бессрочно и восстанавливать за несколько минут. Восстановление на определённый момент времени (PITR) при включении непрерывно сохраняет резервную копию таблицы за последние 35 дней, позволяя восстановить её на любую секунду в этом интервале. Оба типа резервных копий можно экспортировать в S3 для межрегионального резервного копирования или интеграции с AWS Backup. Для рабочих таблиц настоятельно рекомендуется использовать PITR.

Amazon EFS интегрируется с AWS Backup для автоматического ежедневного резервного копирования. Резервные копии EFS являются инкрементальными: после первой копии передаются только изменённые данные, что обеспечивает эффективное использование хранилища. Вы можете восстановить всю файловую систему или отдельные файлы из резервной копии. Для межрегионального DR используйте межрегиональное копирование AWS Backup, чтобы автоматически копировать резервные копии EFS в хранилище региона DR. Обратите внимание: сама EFS уже использует несколько AZ внутри региона, а межрегиональное резервное копирование защищает от сбоев региона.

Не все резервные копии нужно хранить вечно. Разработайте стратегию хранения с учётом требований к RPO и соответствия нормативным требованиям. Распространённый вариант: ежедневные резервные копии в течение 7 дней, еженедельные — в течение 4 недель, ежемесячные — в течение 12 месяцев, ежегодные — в течение 7 лет (схема «дед—отец—сын»). Правила жизненного цикла AWS Backup автоматизируют этот процесс. Для резервных копий, хранящихся в S3, используйте политики жизненного цикла S3, чтобы перемещать старые копии в S3 Glacier или Deep Archive и значительно снижать затраты на хранение.

Блокировка хранилища AWS Backup реализует политику WORM (однократная запись, многократное чтение), которая не позволяет никому — включая пользователей root — удалять резервные копии или изменять блокировку до истечения её срока. Это защищает резервные копии от атак программ-вымогателей и угроз со стороны сотрудников. После применения блокировку хранилища нельзя отключить. Эта функция критически важна для соблюдения требований нормативов, предписывающих использовать неизменяемые резервные копии (SOC 2, PCI DSS, HIPAA). Задайте минимальный и максимальный срок хранения, чтобы резервные копии не удалялись преждевременно.

Создание резервных копий — это только половина задачи: необходимо регулярно проверять, что восстановление работает корректно и укладывается в Ваш RTO. AWS Backup поддерживает планы тестирования восстановления, которые по расписанию автоматически восстанавливают резервные копии в тестовой среде и проверяют успешность восстановления. Без регулярных тестов восстановления во время настоящей аварии Вы можете обнаружить, что резервные копии повреждены, неполны или восстанавливаются гораздо дольше ожидаемого. Фиксируйте время восстановления как фактический показатель RTO.

Сбои резервного копирования необходимо обнаруживать немедленно: неудачное задание резервного копирования означает, что при следующей аварии у Вас не будет актуальной точки восстановления. Настройте уведомления AWS Backup через SNS, чтобы получать оповещения о сбоях заданий резервного копирования. Используйте метрики CloudWatch, например NumberOfBackupJobsFailed, для создания сигналов тревоги. Используйте правила AWS Config, например BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK, чтобы непрерывно проверять наличие подходящих планов резервного копирования у ресурсов. Рассматривайте пропущенное резервное копирование как потенциальное нарушение требований соответствия.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали: AWS Backup централизует управление резервным копированием RDS, DynamoDB, EFS, EC2 и других сервисов, межрегиональная репликация S3 автоматически копирует резервные версии в регион DR, а блокировка хранилища Backup обеспечивает неизменяемые резервные копии для соответствия нормативным требованиям и защиты от программ-вымогателей. Всегда тестируйте восстановление, чтобы проверить фактический RTO. Далее мы рассмотрим стратегии Pilot Light и Warm Standby.