Бэкап виден в списке S3, но это ещё не значит, что его можно сразу скачать. Для S3 Glacier Flexible Retrieval и Deep Archive сначала нужна выдача из архива: запросите восстановление объекта, дождитесь готовности временной копии и только потом забирайте данные.
До аварии проверьте весь путь на одном полноценном комплекте: ожидание выдачи, скачивание, расшифровку и запуск сайта. Если он дольше допустимого простоя, нужна отдельная быстро доступная копия, даже когда холодный архив исправен.
1. Уточните, где лежит нужная версия
Запишите bucket, регион, ключ объекта и, если включено версионирование, VersionId нужной копии. Для многотомного архива составьте список всех частей; для цепочки бэкапов — всех необходимых звеньев. Готовность одного файла не подтверждает готовность комплекта.
Проверьте StorageClass и состояние архива в консоли или через HeadObject. Glacier Instant Retrieval допускает обычное чтение без предварительной выдачи; Flexible Retrieval и Deep Archive требуют restore. У S3 Intelligent-Tiering отдельно проверяйте Archive Access и Deep Archive Access: после выдачи объект возвращается в Frequent Access, а не получает срок временной копии. Это разные механизмы в документации AWS по архивным объектам.
Название «S3-совместимое» само по себе не обещает эти классы и сроки. У другого провайдера проверьте его правила выдачи, стоимость и доступные операции.
2. Сравните ожидание с допустимым простоем
Для обычного восстановления объектов AWS указывает такие типичные сроки:
| Класс хранения | Standard | Bulk | |---|---|---| | Glacier Flexible Retrieval | 3–5 часов | 5–12 часов | | Glacier Deep Archive | до 12 часов | до 48 часов |
У Flexible Retrieval есть Expedited, но у Deep Archive его нет. Ускоренный запрос без заранее выделенной мощности может быть не принят при высоком спросе. Эти ориентиры не являются обещанием восстановления сайта: крупные наборы объектов могут выдаваться дольше, а скачивание и развёртывание идут следом. У Batch Operations есть свои особенности запуска — сверяйте выбранный способ с актуальными вариантами выдачи AWS.
Сопоставьте ожидание с RTO сайта — допустимым временем восстановления. Например, если бизнес допускает простой только на час, холодная копия с многочасовой выдачей не подходит как единственный аварийный источник.
3. Запросите выдачу и проверьте её завершение
Начните с заранее выбранного тестового комплекта и согласуйте расходы на запросы, извлечение, временное хранение и передачу. Не запускайте массовую выдачу всего bucket только ради проверки.
В консоли S3 выберите объект и действие Initiate restore. Для Flexible Retrieval или Deep Archive задайте режим выдачи и число дней доступности временной копии с запасом на скачивание и повторную проверку.
Пример для AWS CLI ниже относится только к этим двум классам. Имена условные, семь дней — пример окна доступности, а не срок хранения исходного бэкапа:
aws s3api restore-object \
--bucket BACKUP_BUCKET \
--key 'backups/site.tar.gz' \
--restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'Если нужна конкретная версия, добавьте её --version-id и используйте ту же версию во всех дальнейших операциях. Иначе можно проверить свежий файл вместо копии, которая понадобится при аварии. Параметры описаны в справочнике restore-object.
Проверьте состояние:
aws s3api head-object \
--bucket BACKUP_BUCKET \
--key 'backups/site.tar.gz' \
--query '{Class:StorageClass,Restore:Restore,Bytes:ContentLength}'В поле Restore значение ongoing-request="true" означает ожидание, а ongoing-request="false" — завершение выдачи. Для этих классов там же указан expiry-date временной копии. Успешное принятие запроса ещё не означает готовность файла; порядок проверки есть в инструкции AWS по восстановлению.
4. Доведите проверку до рабочего сайта
После выдачи скачайте полный комплект в защищённую среду. Проверьте контрольные суммы, чтение архива и доступность ключа расшифровки, затем выполните пробное восстановление на изолированном стенде без реальных платежей, писем и вебхуков.
Если загрузка не идёт, разделяйте причины:
- restore ещё выполняется — дождитесь готовности нужных объектов;
- окно временного доступа закончилось — проверьте expiry-date и запросите выдачу заново;
- получен отказ доступа — проверьте права на выбранную версию и расшифровку; не открывайте bucket публично;
- скачана только часть комплекта — сверьте список объектов, версии и размеры до распаковки.
Срок временной копии не отменяет правила удаления исходного объекта: проверьте Lifecycle отдельно. Не считайте тестовое восстановление продлением хранения бэкапа.
Что записать в аварийную инструкцию
Зафиксируйте время запроса, готовности последнего нужного объекта, окончания скачивания и успешного запуска. Отдельно отметьте затраты времени на доступы и ручные действия. Так станет видно, на каком этапе теряется запас до RTO.
Если запас недостаточен, оставьте проверенный аварийный комплект в классе с немедленным чтением, пересмотрите правила его перехода в архив и повторите замер. Единственный небольшой тест не доказывает скорость выдачи всего сайта.
Web-Puls помогает наблюдать за доступностью публичного сайта после восстановления; мониторинг URL не выдаёт S3-архив и не проверяет пригодность резервной копии.
Если срок выдачи не укладывается в план или комплект не разворачивается, можно отправить заявку на профессиональную поддержку. Укажите публичный адрес сайта, класс хранения, объём комплекта и этап остановки; ключи доступа, подписанные ссылки и сами бэкапы в форму не прикладывайте.