Бэкап есть. А восстановиться получится?

Что именно сохраняем

Логический дамп удобен для отдельной базы: его можно перенести на другой сервер и восстановить выборочно. Но pg_dump не сохраняет роли всего кластера и не заменяет архивирование WAL для восстановления на произвольный момент времени.

Заранее опишите допустимую потерю данных (RPO) и время восстановления (RTO). Ежесуточный дамп может оказаться недостаточным даже при полностью исправной копии.

Минимальный тест в изолированной базе

Ниже учебный пример. app — исходная база, а restore_check — отдельная пустая база в тестовом окружении. Учётные данные передаются средствами PostgreSQL; пароль не нужно записывать в команду.

pg_dump --format=custom --file=app.dump --dbname=app
createdb --template=template0 restore_check
pg_restore --exit-on-error --no-owner --no-privileges \
  --dbname=restore_check app.dump
psql -X --set=ON_ERROR_STOP=on --dbname=restore_check \
  --command='SELECT count(*) FROM public.orders;'

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

Что считать успешной проверкой

• Создание дампа и восстановление завершились с нулевым кодом возврата.
• Нужные схемы и таблицы существуют, контрольные запросы проходят.
• Изолированное приложение выполняет основные операции.
• Известны длительность восстановления, размер копии и её возраст.

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

Как превратить проверку в процесс

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