31 января 2017 года инженер GitLab удалил около 300 ГБ с primary-базы PostgreSQL. Восстановление из pg_dump не сработало: задание запускало клиент PostgreSQL 9.2 против сервера 9.6, а письма об ошибках отбрасывал DMARC. Инцидент продлился 18 часов 30 минут.
Рабочей оказалась LVM-копия staging на 17:20 UTC. GitLab поднялся 1 февраля в 18:00, но изменения между 17:20 и 23:30 потеряли безвозвратно.
Статус Completed в такой ситуации бесполезен. Тебе нужно другое доказательство: отдельная база поднялась из recovery point, приняла подключение, вернула ожидаемые данные и уложилась в RTO.
AWS Backup Restore Testing автоматизирует эту проверку. Сервис регулярно выбирает recovery point, восстанавливает ресурс и измеряет продолжительность restore job.
Успешный backup job проверяет процесс, а не данные
Задание может завершиться без ошибки, хотя копия неполна или повреждена. Скрипт не прочитал каталог из-за прав, snapshot захватил рассогласованное состояние, хранилище испортило блоки — а мониторинг получил зелёный статус.
Размер файла и продолжительность задания помогают заметить сбой раньше. Например, дамп внезапно уменьшился с 80 до 12 ГБ или вместо привычных 40 минут отработал за три. Это повод остановить ротацию и проверить копию, но не доказательство её исправности.
Checksum отвечает только на вопрос, изменился ли файл. Он не покажет, запускается ли PostgreSQL, открывается ли контрольная таблица и сохранились ли нужные строки. Восстановимость подтверждает лишь restore test.
Restore Testing поднимает recovery point по расписанию
Restore testing plan хранит имя, частоту и время запуска. При каждом прогоне AWS Backup выбирает один подходящий recovery point для каждого защищённого ресурса и запускает тот же механизм восстановления, что используется при on-demand restore.
Функция работает с Amazon RDS, Aurora, DynamoDB, EBS, EC2, EFS, S3, DocumentDB, FSx, Neptune и рядом других сервисов. Но статус available подтверждает только готовность ресурса со стороны AWS. Данные всё ещё должен проверить твой код.
Для PostgreSQL проверка может выглядеть так:
psql \
"host=$RESTORE_HOST port=5432 dbname=$DB_NAME user=$DB_USER sslmode=require" \
-v ON_ERROR_STOP=1 \
-c "SELECT id, created_at FROM backup_probe WHERE id = 1;"Порт PostgreSQL — 5432. Таблицу backup_probe и ожидаемую строку создай заранее в production. Тогда тест проверит не только TCP и аутентификацию, но и наличие конкретных данных в восстановленной базе.
Добавь ещё один запрос, связанный с рабочим сценарием: количество заказов за закрытый день, максимальный event_id или наличие завершённой миграции. Проверка SELECT 1 слишком слабая — она доказывает только то, что сервер отвечает.
Фактический RTO получают из прогонов
В одном исследованном сценарии RDS PostgreSQL объёмом 100 ГБ на db.t3.medium переходил в состояние available за 20–40 минут. Это ориентир для конкретной конфигурации, а не обещание AWS.
Твой RTO зависит от движка, объёма, класса инстанса и прикладной проверки. Замеряй интервал от запуска restore job до успешного контрольного запроса. Если база стала available за 28 минут, а миграции и проверка данных заняли ещё 17, фактический RTO равен 45 минутам.
AWS Backup Audit Manager умеет сопоставлять продолжительность восстановления с целевым временем. Запуск теста также создаёт вызов StartRestoreJob в CloudTrail, если сервис подключён к журналированию. Эти записи дают проверяемую историю для разбора инцидентов и аудита.
IAM-роль должна уметь восстановить и удалить RDS
Для проверки RDS роли нужны как минимум следующие действия:
rds:RestoreDBInstanceFromDBSnapshot
rds:DescribeDBSnapshots
rds:DescribeDBInstances
rds:DeleteDBInstance
kms:DecryptПраво kms:Decrypt ограничь KMS-ключом, которым зашифрован snapshot. Без удаления тест пройдёт лишь наполовину: база поднимется, а временный инстанс продолжит работать и начислять расходы.
Не проверяй расписание по одному cron-выражению. AWS Backup вычисляет запуски внутри интервала с 00:00 до 23:59. План с частотой «каждые 12 часов» и временем старта после 11:59 запустится только раз в сутки. Сверь расчёт с фактической историей restore jobs.
Автоматическое удаление тоже входит в тест
После окна валидации AWS Backup удаляет восстановленный ресурс. Если тип ресурса поддерживает tag-on-restore, сервис добавляет тег awsbackup-restore-test. Снимать его нельзя: без тега AWS Backup не удалит ресурс автоматически.
DynamoDB, S3, SAP HANA on EC2, виртуальные машины и Timestream не поддерживают tag-on-restore. Для них жизненный цикл нужно учитывать отдельно. Удаление тестового S3-бакета может занять несколько дней из-за lifecycle rules.
Поэтому прогон заканчивается не на available и не после контрольного SELECT. Он заканчивается, когда система сохранила фактический RTO и подтвердила удаление временного ресурса.
На следующем дежурстве считай бэкап рабочим только при трёх результатах:
- AWS восстановил recovery point в отдельный ресурс.
- Прикладной запрос вернул ожидаемые данные.
- Мониторинг записал RTO и подтвердил удаление ресурса.
Completed без этих результатов означает лишь, что задание закончилось. Если нужно сначала проверить процедуру руками, используй инструкцию про бэкап PostgreSQL в S3 и проверку восстановления.
