Репетиция восстановления из бэкапа: проверяем PostgreSQL 16

Успешное создание дампа PostgreSQL ещё не доказывает, что из него получится вернуть работающий сервис. Это выяснится только при восстановлении: архив может оказаться неполным, а на целевом сервере — не хватить расширения или прав. Репетиция на PostgreSQL 16 проверяет не только файл, но и путь от него до готового приложения; заодно вы измерите фактическое время восстановления.

Что именно проверяет репетиция

В этой инструкции — логический архив, созданный утилитой pg_dump в формате custom, и восстановление через pg_restore. Пример рассчитан на PostgreSQL 16 и соответствующие клиентские утилиты. Это не инструкция по физическому резервному копированию или восстановлению на конкретный момент времени: у них другой процесс и другие проверки.

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

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

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

Подготовьте безопасный стенд

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

До начала проверьте, что у вас есть:

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

Клиентские утилиты можно проверить командами pg_dump --version и pg_restore --version. Учтите, что дамп одной базы не включает глобальные объекты кластера, например роли. Если приложение зависит от них, включите восстановление ролей в отдельную часть плана и отрабатывайте её в изолированной среде.

Восстановите архив и проверьте результат

Ниже предполагается, что дамп доступен по пути /secure/path/appdb.dump, а соединение с PostgreSQL настроено через стандартные параметры клиента. Подставьте свой путь и имя исходной базы. Не помещайте пароль в командную строку или историю терминала.

1. Запишите исходные условия. Зафиксируйте время начала, размер и дату дампа, версии сервера и клиентских утилит, доступные CPU, память и диск. Проверьте, что это именно архив PostgreSQL, а не пустой файл. Так результат следующего учения можно будет сравнить с текущим.
2. Проверьте, что архив читается. Выполните pg_restore --list /secure/path/appdb.dump. Утилита должна вывести список объектов архива. Это проверка читаемости списка, а не доказательство, что все данные восстановятся.
3. Создайте отдельную пустую базу. Например, createdb --template=template0 restore_drill. Если база с таким именем уже существует, выберите новое имя, а не удаляйте её наугад. Проверка: команда завершилась без ошибки, целевая база доступна для подключения.
4. Восстановите архив. Запустите pg_restore --exit-on-error --verbose --no-owner --no-privileges -d restore_drill /secure/path/appdb.dump. Флаг --exit-on-error нужен, чтобы ошибка не затерялась среди сообщений и восстановление остановилось. Команда не удаляет исходную базу и не очищает целевую, но запускать её следует именно в созданную для учения пустую базу.
5. Проверьте структуру и данные. Подключитесь к восстановленной базе и сверьте обязательные таблицы, критичные записи и количество строк там, где оно известно. Затем запустите прикладные проверки: например, чтение ключевой сущности или вход тестового пользователя. Одного успешного соединения с базой для этого недостаточно.
6. Остановите таймер и запишите результат. RTO завершён не тогда, когда команда вернула приглашение, а когда приложение прошло согласованные проверки. Сохраните журнал ошибок и длительность каждого этапа; после учения удалите тестовые данные по правилам вашей организации.

Опции --no-owner и --no-privileges упрощают восстановление в тестовую базу без исходных владельцев и прав доступа. Поэтому такой тест подтверждает переносимость данных и объектов, но сам по себе не проверяет, смогут ли рабочие роли и пользователи подключиться после аварии. Если для эксплуатации важны исходные владельцы и привилегии, отработайте их восстановление отдельно на стенде.

Какие результаты считать достаточными

Не подставляйте в отчёт универсальные «нормальные» минуты и проценты: скорость зависит от объёма данных, диска, сети, настроек и доступных ресурсов. Сравнивайте замеры одного и того же процесса на сопоставимом окружении. Если RTO превышен, разбейте его на этапы — перенос файла, создание базы, восстановление, прикладная проверка — и выясните, где уходит время.

Бэкап становится планом восстановления только после того, как из него на отдельном стенде вернули данные и подтвердили работу приложения.

Где репетиция может дать ложное чувство безопасности

Самая частая ошибка — восстановить базу, увидеть завершившуюся команду и объявить учение успешным. Это не проверяет корректность важных для бизнеса данных и не позволяет судить, переживёт ли сервис переключение. Состав проверок должен отвечать на вопрос «что пользователь должен суметь сделать», а не только «открывается ли соединение».

• Расширения не установлены. Если архив ссылается на расширение, которого нет на тестовом сервере, восстановление может остановиться. Сверьте зависимости базы и заранее установите необходимые компоненты из доверенного источника.
• Не хватает ролей или прав. Восстановление с параметрами выше не воспроизводит исходные привилегии. Проверьте, каким пользователем приложение подключается и как в аварийном плане возвращаются роли.
• Стенд слишком слабый или не похож на рабочий. Время восстановления на нём нельзя механически переносить на другое оборудование. Зафиксируйте различия в ресурсах и повторите замер в условиях, близких к аварийному сценарию.
• Учение затронуло действующую систему. Ошибка в имени базы, скрипте или конфигурации может привести к работе с не тем окружением. Используйте отдельное имя базы и проверяйте адрес подключения перед каждой командой.
• Дамп восстановился, но внешние части сервиса — нет. Файлы в объектном хранилище, очереди, секреты и настройки приложения могут храниться отдельно. Включите их в сценарий, если без них пользовательский путь не работает.

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

Что сделать после учения

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

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