Резервная копия PostgreSQL: проверяем восстановление, а не размер файла

Команда pg_dump завершилась успешно. Следующий шаг — не смотреть на размер файла, а попробовать pg_restore в отдельной базе. Только так станет видно, хватает ли объектов, расширений и настроек для запуска приложения. Разберём простой цикл проверки копии и то, чего дамп одной базы в себе не содержит.

Создаём архив

pg_dump -h 127.0.0.1 -U backup_user -Fc \
  -f app-backup.dump app
pg_restore --list app-backup.dump > app-backup.contents.txt

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

Восстанавливаем в отдельную базу

createdb -h 127.0.0.1 -U restore_user app_restore_check
pg_restore -h 127.0.0.1 -U restore_user \
  --exit-on-error --no-owner --no-privileges \
  -d app_restore_check app-backup.dump

Название app_restore_check специально отличается от рабочей базы. Не направляйте эту проверку на production. Здесь владельцы и права из архива не воспроизводятся: это упрощает изолированный тест, но означает, что управление доступом нужно проверять отдельным сценарием.

Что сверить после команды

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

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

Источники и дальнейшее чтение

• PostgreSQL 15: логическое резервирование
• PostgreSQL 15: pg_restore