Резервные копии restic в R2: от сохранения до проверенного восстановления

Завершённое задание не доказывает возможность вернуть нужные данные. Этот обобщённый внутренний пример раздельно оценивает хранение, целостность, восстановление данных и сервиса. Это не отчёт о завершённой миграции с другого сервиса.

Фиксация ID снимка и одной цели восстановления

Запишите ID снимка и восстановите нужные файлы в пустое изолированное место. Для конфигурации проверьте ссылки и права, для БД — загрузку в изоляции. Измерьте время. Регулярно повторяйте одинаковые проверки, сравнивая свежесть и доступный объём восстановления.

restic：Восстановление в изолированное место

Определить источник и успех

Используются шифрование и дедупликация restic с S3-совместимым API R2. Проверьте нужные операции по таблице совместимости. Для работающих баз обеспечьте согласованный сбор через дампы или подходящую остановку записи приложения.

Следить за свежестью отдельно

Отслеживайте последний успешный снимок, задержки, ошибки и результаты проверки/восстановления раздельно. Запуск задания не означает успех. Ошибка уведомления также отличается от ошибки копирования.

Проверить целостность и извлечение

Обычный restic check и проверки с чтением данных имеют разный охват. --read-data читает все данные; охват частичной проверки фиксируется. Совмещайте проверки репозитория, восстановление в отдельное место и сравнение содержимого или хешей. Извлечение файлов не проверяет запуск приложения.

Управлять хранением через restic

Выбирайте снимки политикой restic, используйте forget, prune, check и заранее проверяйте, что останется. Удаление объектов R2 только по возрасту может уничтожить общие данные сохранённых снимков. Следуйте документации хранения; очистка объектов доставки изображений — другой случай.

Оставшиеся проверки

Выполнены регулярная работа, мониторинг/уведомления, управление хранением и извлечение/целостность выбранных данных. Запуск всех приложений, восстановление настроек и зависимостей, доступ к отдельно хранимым учётным данным требуют сквозной проверки. Время восстановления и допустимая потеря данных требуют измерения. Полное аварийное восстановление и доказанная экономия не заявляются.

1. 1 Успешный snapshot и его свежесть Проверьте время действительно успешного snapshot и задержку относительно расписания. Сам запуск задания не означает успех.
2. 2 Целостность и изолированное восстановление Зафиксируйте охват проверки, выполните restore --verify в отдельном месте и сравните нужные файлы и hash, затем проверьте хранение и prune.
3. 3 Полное аварийное восстановление Запуск всех приложений, зависимые данные и восстановление отдельно хранимых учётных данных остаются непроверенными. Время восстановления и допустимая потеря данных не измерялись.

Дополнение от 6 октября 2026 года: устаревшие блокировки и конкуренция при проверке восстановления

Дополнительное изменение сначала проверяет активность процессов на том же хосте, а затем выполняет обычную разблокировку restic, которая обрабатывает только устаревшие блокировки. Опция удаления всех блокировок, включая блокировки активных операций, не используется. При конфликтах выполняются ограниченные повторы с –retry-lock; при ошибке проверки восстановления и prune процесс не перезапускается бесконечно. Проверка активности на одном хосте не доказывает отсутствие конкурирующей операции на другом хосте.

Данные извлекаются командой restore –verify в изолированный временный каталог. После проверки нужных файлов и их целостности фиксируется соответствие проверенного снимка и конфигурации. Сначала подтверждается восстановление целевых данных, затем перед prune проверяются данные, которые следует сохранить. Актуальность резервной копии определяется по снимку, успешно завершившемуся на деле, а не по запуску процесса или повторным попыткам.

Подтверждённое восстановление целевых данных по-прежнему отличается от полного восстановления, включающего запуск всех приложений и восстановление учётных данных. Об обработке окон обслуживания и сбоев сбора см. также Мониторинг и расследование инцидентов.