Восстановление из бэкапа на сервере: разбор проекта

Сбой обычно начинается не с кнопки «восстановить». Приложение продолжает принимать заказы, база уже повреждена или откатилась на несколько часов, а файлы пользователей лежат в отдельном каталоге. На примере типового проекта с PostgreSQL 16, приложением за Nginx и файловым хранилищем разберём сценарий восстановления на сервере: что остановить, как проверить резервную копию, когда переключать трафик и какие данные потеряются при разных вариантах.

Сценарий: база и файлы живут отдельно

Возьмём проект с тремя компонентами:

• приложение принимает запросы через Nginx;
• PostgreSQL 16 хранит пользователей, заказы и настройки;
• загруженные документы и изображения лежат в файловом каталоге, который копируется отдельно от базы.

Это не «готовая инструкция для любого сервера». Формат резервной копии, пользователь базы, способ запуска приложения и расположение файлов нужно сверить с вашей конфигурацией. В статье рассматривается операционный сценарий: рабочий сервер ещё доступен, но данные нужно вернуть к моменту последней корректной копии.

Резервная копия считается рабочей не тогда, когда файл существует, а тогда, когда из него можно поднять отдельную копию проекта и проверить бизнес-сценарий.

RPO — допустимая потеря данных по времени: например, последние несколько часов между копиями. RTO — допустимое время восстановления сервиса. Эти два показателя нужно записать до аварии, иначе команда будет спорить о приоритетах уже во время простоя.

Что проверить до восстановления

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

1. Остановите автоматические изменения. Отключите фоновые задачи, очереди, cron и запись через административную панель. Если это невозможно, временно переведите приложение в режим только для чтения. Иначе после восстановления новые данные снова начнут смешиваться со старой базой.
2. Снимите текущую копию. Даже повреждённая база и нынешний каталог загрузок могут понадобиться для разбора и выборочного переноса. Не удаляйте их до окончания проверки.
3. Определите точку восстановления. Запишите дату и время копии, часовой пояс, тип бэкапа и список компонентов, которые в неё входят. Дамп PostgreSQL не содержит автоматически файлы, которые приложение хранит на диске.
4. Проверьте свободное место. Для распаковки и восстановления часто нужны исходный файл, временные данные и уже созданная база. Если диск заполнится посередине операции, вы получите ещё одну неисправность вместо результата.
5. Проверьте права доступа. Процесс PostgreSQL должен читать файл дампа, а приложение — видеть восстановленные файлы с теми же владельцем и разрешениями, что и до сбоя.

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

Почему восстановление на том же сервере опасно

На практике есть три подхода. Они отличаются не только удобством, но и ценой ошибки.

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

Как восстановить PostgreSQL 16 без угадывания формата

Сначала определите тип резервной копии

Расширение файла не всегда надёжный признак. Дамп, созданный в формате PostgreSQL custom, восстанавливают через pg_restore. Текстовый SQL-файл передают клиенту psql. Это разные операции: команда для одного формата не обязана работать с другим.

Для custom-дампа схема действий выглядит так:

# Выполняйте после создания отдельной базы и проверки имени целевой базы
pg_restore --clean --if-exists --no-owner --dbname=APP_DB backup.dump

Для текстового SQL-дампа используется другой вариант:

# ON_ERROR_STOP прекращает импорт при первой ошибке SQL
psql --set=ON_ERROR_STOP=on --dbname=APP_DB < backup.sql

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

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

Файлы и база: точка рассинхронизации

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

1. восстановите файловый каталог во временное расположение, не стирая текущий;
2. проверьте владельца и права на каталоги, которые читает приложение;
3. сопоставьте несколько записей базы с реальными файлами по идентификаторам и путям;
4. только после проверки подключите восстановленный каталог к тестовому экземпляру приложения;
5. после переключения запретите старому процессу снова писать в прежнее хранилище.

Если файлы копируются через rsync, снапшот диска или объектное хранилище, правила проверки будут различаться. Инвалидация кешей, CDN и фоновых очередей — отдельная тема; здесь важен только порядок возвращения базы и файлов к одной временной точке.

Проверка перед переключением трафика

Не открывайте восстановленный экземпляр пользователям сразу. Сначала проведите короткий приёмочный прогон через внутренний адрес или временный маршрут:

• вход в аккаунт и выход из него;
• создание тестовой записи в отдельном тестовом контуре, если это возможно;
• просмотр существующего заказа и связанного файла;
• операция, которая раньше приводила к ошибке;
• проверка фоновых задач: не запустили ли они повторную отправку писем или списание платежа;
• проверка логов приложения, PostgreSQL и Nginx после нескольких запросов.

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

Что измерить, а не оценивать на глаз

Если реальных замеров ещё нет, не подставляйте в план выдуманное время. Во время тестового восстановления запишите:

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

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

Где подход ломается

Дамп повреждён или неполный

Файл может успешно скачаться, но содержать не весь архив. Сверяйте контрольную сумму, размер и результат тестового восстановления. Если резервная система хранит манифест, сравните с ним перечень файлов.

Версия PostgreSQL отличается

Восстановление между версиями PostgreSQL иногда работает, но рассчитывать на это без проверки нельзя. Клиентские утилиты и сервер должны быть совместимы с форматом операции; отдельно тестируйте расширения и параметры, которые использует приложение. Для production-переезда заранее поднимите копию на той же основной версии PostgreSQL 16.

Секреты и конфигурация остались прежними

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

Очереди повторили внешние действия

Повторная обработка задания может создать дубль заказа, письма или webhook-запроса. Запускайте воркеры после ревизии очереди, а внешние операции сверяйте по идентификаторам и журналам поставщика.

Что делать дальше

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

Минимальный критерий готовности — команда может назвать фактические RPO и RTO, поднять копию без догадок и доказать, что пользователь видит не только восстановленные строки базы, но и связанные файлы. Следующим показателем для мониторинга сделайте возраст последней успешной копии и дату последнего успешного тестового восстановления.

Версия примеров: PostgreSQL 16. Перед применением проверьте синтаксис и ограничения вашей версии, способ подключения и формат конкретного дампа.