Как проверить резервную копию: восстановление проекта

Что нужно для восстановления проекта

Составьте список того, что придётся вернуть. Обычно это база данных, пользовательские файлы, код или образ приложения, настройки, секреты и доступы к зависимостям. У проекта могут быть отдельные ключи шифрования, сертификаты, очередь и документы в объектном хранилище.

Для каждого компонента укажите место копии, дату, способ получения и человека, который может дать доступ. Копия бесполезна, если пароль от неё остался только на сервере, который вы собираетесь восстанавливать.

Сразу определите, что можно получить заново, а что существует в единственном экземпляре. Код в доступном репозитории можно собрать. Фотографии пользователей без другой копии заново не появятся.

Подготовьте отдельную среду для проверки

Не проверяйте восстановление поверх рабочей базы. Возьмите отдельный сервер или изолированную среду с понятным адресом и достаточным местом. Ограничьте доступ. В копии могут находиться реальные данные пользователей.

Отключите отправку писем, внешние списания и задачи, которые меняют рабочие системы. Используйте тестовые ключи там, где это возможно. Проверьте адреса подключения, чтобы восстановленное приложение не записывало данные обратно в рабочую базу.

Установите подходящие версии базы и приложения. Совместимость копии зависит от инструмента и формата. Не считайте смену версии безопасной только потому, что файл удалось распаковать.

Восстановите базу, файлы и приложение

Начните с получения копии тем способом, который будет доступен при настоящем восстановлении. Если для выгрузки нужен человек с правами администратора, включите ожидание этого доступа в замер времени. Ручная передача файла в обход обычного порядка скроет проблему.

Проверьте читаемость архива и результат восстановления. Контрольная сумма помогает обнаружить изменение файла, но не подтверждает, что в нём есть все нужные данные. Прочитайте журнал инструмента, разберите ошибки и проверьте права пользователя приложения.

У PostgreSQL формат дампа определяет инструмент восстановления: обычный SQL загружается через psql, архивные форматы — через pg_restore. Роли не входят в дамп одной базы. Проверяйте это по документации PostgreSQL, а не по случайной команде из чужого проекта.

Восстановите файлы в ожидаемые пути и проверьте владельца и права. Для Docker отдельно учитывайте данные томов и bind mounts. Сам образ не заменяет их копию. Принцип работы томов есть в руководстве Docker.

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

Проверьте полноту и актуальность данных

Посмотрите последние записи, важные документы, связи между таблицами и вложениями. Сравнивайте с заранее известными контрольными данными. Количество строк полезно, но само по себе не показывает, что записи правильные.

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

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

Пройдите основные пользовательские сценарии

Войдите в приложение тестовой учётной записью. Создайте и измените запись, найдите старые данные, откройте вложение и загрузите новый файл. Проверьте фоновую задачу и уведомление через тестовый канал.

Убедитесь, что результаты действительно сохраняются в восстановленной среде. Проверьте её адреса подключения, логи и очередь. Если проект зависит от стороннего сервиса, отмечайте отдельно, что проверили реально, а что только заменили заглушкой.

Критерий успеха должен быть понятным: какие действия работают, какие данные доступны и какие ограничения остались. Формулировка «контейнер поднялся» для этого слишком слабая.

Замерьте время и допустимую потерю данных

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

RTO — целевой срок восстановления. RPO — допустимый период потери данных. Проверка показывает, соответствуют ли реальные копии и порядок действий этим требованиям. Не подгоняйте цифры в отчёте, если ожидали час, а получилось шесть.

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

Что сохранить и когда повторять проверку

Запишите, какую копию использовали, какие версии запускали, сколько времени заняли шаги и какие проверки прошли. Секреты в такой отчёт не добавляйте. Рядом нужен порядок восстановления, который сможет выполнить другой инженер.

Повторяйте проверку после существенных изменений приложения, базы и хранения данных. Частоту регулярных проверок выбирают по важности проекта и скорости изменений. Старая успешная попытка не гарантирует, что новая копия тоже пригодна.

После проверки удалите тестовые данные и среду по согласованному порядку. Учебное приложение тоже подходит для такой практики. Начать можно с развёртывания на VPS, а следующая задача — перенос на другой сервер.

Частые вопросы

Можно ли проверить копию без отдельного сервера?

Можно использовать другую изолированную среду, если она подходит для приложения и не затрагивает рабочие данные. Важно реально восстановить проект, а не только проверить архив.

Что делать, если восстановление базы прошло с ошибками?

Проверку нельзя считать успешной. Нужно разобрать ошибки, исправить недостающие зависимости или права и повторить восстановление и проверку данных.

Как часто проверять восстановление?

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