Резервное копирование и восстановление PostgreSQL

Резервное копирование окупается в первую секунду реальной аварии. Ниже — логические и физические стратегии, PITR, промышленные инструменты и чек-лист проверки.

Золотое правило

Бэкап, который никогда не восстанавливали, — слабое подстрахование.

Планируйте регулярные тестовые восстановления на отдельный стенд: целостность, время (RTO), актуальность данных (RPO).

Два семейства бэкапов

Практика: для критичных систем часто комбинируют физический бэкап + WAL (DR и PITR) и периодические логические дампы (миграции, юридический снимок схемы).

Логический бэкап: pg_dump и pg_dumpall

Одна база (формат custom)

pg_dump -U postgres -h localhost -p 5432 -F c -b -v -f /backups/db_$(date +%Y%m%d).dump mydb

• -F c — custom (сжатие, параллельное pg_restore -j)
• -b — large objects
• Путь к файлу — абсолютный, каталог заранее создайте и проверьте права

Весь кластер (роли, глобальные объекты)

pg_dumpall -U postgres -f /backups/cluster_$(date +%Y%m%d).sql

Пример cron

0 2 * * * /usr/bin/pg_dump -U postgres -F c -f /backups/db_$(date +\%Y\%m\%d).dump mydb 2>> /var/log/pg_backup.log
0 3 * * * find /backups -name "*.dump" -mtime +30 -delete

Логируйте время, размер, код возврата; при ошибке — алерт в мониторинг.

Физический бэкап и WAL-архивация

postgresql.conf (идея)

wal_level = replica
archive_mode = on
archive_command = 'cp %p /backup/wal_archive/%f'

cp годится для демо; в проде — rsync, облако, wal-g и т.д. Команда должна возвращать 0 только при успехе, иначе PostgreSQL будет повторять архивацию.

Базовый снимок

pg_basebackup \
  -h postgres.internal \
  -U backup_user \
  -D /backup/base/$(date +%Y%m%d_%H%M) \
  -Ft -z \
  --wal-method=stream \
  --checkpoint=fast \
  --progress

-Ft -z — tar + gzip; --wal-method=stream — WAL в потоке во время бэкапа.

PITR (точка во времени)

Сценарий: откатиться на секунду до ошибочного DELETE.

1. Остановить PostgreSQL:

sudo systemctl stop postgresql

1. Очистить PGDATA и распаковать базовый бэкап (пути под вашу версию и layout):

rm -rf /var/lib/postgresql/*/main/*
tar -xzf /backup/base/20250115_0200/base.tar.gz -C /var/lib/postgresql/16/main
tar -xzf /backup/base/20250115_0200/pg_wal.tar.gz -C /var/lib/postgresql/16/main/pg_wal

1. Восстановление (PostgreSQL 12+): restore_command и цель в postgresql.conf или auto.conf, плюс файл recovery.signal в PGDATA для запуска в режиме восстановления (в актуальных версиях см. документацию: для promote используется recovery_target_action и т.д.).

Пример параметров:

restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2025-12-28 14:31:59'
recovery_target_action = 'promote'

touch /var/lib/postgresql/16/main/recovery.signal
sudo systemctl start postgresql

Кластер применит WAL до цели и выйдет в нормальный режим согласно recovery_target_action.

Промышленные инструменты

pgBackRest

Полные / дифференциальные / инкрементальные бэкапы, параллельность, сжатие, --archive-async, шифрование, облака. Частый выбор для крупных инсталляций без отдельного «backup-сервера приложения».

Barman

Централизованно несколько серверов; RPO≈0 возможен через поток pg_receivewal вместо только archive_command на завершённые 16 МБ сегменты. Популярен в enterprise-окружении.

WAL-G

Поток в S3 / GCS / Azure, инкременты для больших баз — типичный cloud-native вариант.

Что выбрать (очень грубо)

• Мало серверов, руками: pg_basebackup + cron + вынос копий offsite
• До нескольких ТБ: pgBackRest
• Нужна «коробка» и много инстансов: Barman
• Объектное хранилище как основной таргет: WAL-G

Правило 3-2-1 и чек-лист

3 копии, 2 типа носителя, 1 offsite.

Ежемесячно проверяйте:

• Дамп/бэкап завершается с кодом 0
• Подъём на тестовом хосте и smoke-SQL
• Ключи шифрования и восстановление из шифра
• RTO в пределах SLA
• Retention и свободное место
• Актуальная runbook в wiki
• Алерты на сбои бэкапа доходят до дежурных

Типичные ошибки

Итог

Определите RPO/RTO, выберите связку логический + физический + WAL, автоматизируйте и проверяйте восстановление чаще, чем раз в год.