Стратегия резервного копирования PostgreSQL: когда использовать pg_dump, физические бэкапы и архивацию WAL?

Различия между логическим и физическим бэкапом, восстановление на момент времени (PITR), удаленные копии, шифрование и практический план проверок восстановления с примерами команд.

2026-09-12

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

Два основных метода

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

Экспортирует содержимое базы данных в формате SQL или специальном архивном формате. Переносим между версиями, позволяет легко восстановить отдельную таблицу, подходит для баз данных малого и среднего размера. Недостатки: изменения между моментом создания бэкапа и моментом инцидента теряются, а на больших базах процесс может занять много времени.

# Специальный формат, сжатый, одна база данных
pg_dump -Fc -Z 6 -d app -f /backups/app_$(date +%F_%H%M).dump

# Роли и настройки кластера (необходимо делать отдельно)
pg_dumpall --globals-only -f /backups/globals_$(date +%F).sql

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

Создает согласованную копию каталога данных; при добавлении архива WAL (write-ahead log) становится возможным восстановление на определенный момент времени (PITR). Это единственный способ реализовать сценарий «вернуть случайно удаленную в 14:32 таблицу на состояние 14:31». Это стандартный подход для больших баз данных и низкой толерантности к потере данных.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'

# Базовый бэкап
pg_basebackup -D /backups/base_$(date +%F) -Ft -z -Xs -P

В корпоративных средах такие инструменты, как pgBackRest или Barman, управляют этим процессом: они предлагают полный/инкрементальный бэкап, политику хранения, верификацию и поддержку удаленного хранилища.

Какой метод в какой ситуации?

ПотребностьРекомендуется Маленькая база данных, суточная потеря допустимаЕжедневный pg_dump + удаленная копия Допустимая потеря на уровне минутФизический бэкап + архив WAL (PITR) Необходимость восстановления одной таблицы / схемыАрхивный формат pg_dump (выборочное восстановление) Перед обновлением версииОба метода одновременно

3-2-1 и неизменяемость

Три копии, две разные среды, одна копия на другой площадке. Для удаленной копии объектное хранилище (S3-совместимые сервисы или собственная инсталляция MinIO) является популярным выбором; такие функции, как «object lock», предотвращающие удаление бэкапов в течение определенного времени, имеют решающее значение в сценариях с программами-вымогателями. Удаленная копия должна защищаться с помощью раздельных прав доступа, исключающих ее удаление с учетными данными производственного сервера.

Шифрование

Файлы бэкапов содержат персональные и финансовые данные; TLS при передаче и шифрование в хранилище обязательны. Ключ не должен храниться в том же месте, что и бэкап; в противном случае шифрование носит лишь видимый характер. Потеря ключа означает потерю бэкапа; управление ключами является частью плана.

Бэкап, для которого не проводилось тестирование восстановления, — это всего лишь надежда. Проверка не должна проводиться в день, когда бэкап действительно понадобился впервые.

Тестирование восстановления: измеряйте RTO и RPO

Регулярно восстанавливайте бэкап на отдельный сервер (или временный контейнер), подключайте к нему приложение, выполняйте базовые операции и фиксируйте время. Если измеренное время превышает целевой показатель восстановления (RTO), метод необходимо изменить. В средах с Docker тестирование можно автоматизировать:

docker run --rm -d --name pg_restore_test -e POSTGRES_PASSWORD=test postgres:16
docker cp /backups/app_latest.dump pg_restore_test:/tmp/app.dump
docker exec pg_restore_test pg_restore -U postgres -d postgres --create /tmp/app.dump
docker exec pg_restore_test psql -U postgres -d app -c "select max(created_at) from orders;"

Мониторинг: знать, если бэкап не удался

Необходимо отслеживать не факт запуска задачи бэкапа, а ее успешное завершение и соответствие размера файла ожидаемому. Правило «последний успешный бэкап старше 24 часов» должно вызывать предупреждение. Тихо падающие бэкапы — самый частый сценарий катастрофы.

Заметка о саморазвертывании Supabase

Если вы запускаете Supabase на собственном сервере, одного бэкапа PostgreSQL недостаточно: объекты хранилища (storage), конфигурация и секретные ключи также должны резервироваться; в противном случае база данных восстановится, но файлы и конфигурация аутентификации — нет.

Восстановление на момент времени (PITR) шаг за шагом

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

# 1. Распакуйте базовый бэкап в новый каталог данных
mkdir /var/lib/postgresql/restore && tar -xzf /backups/base_2026-10-01/base.tar.gz -C /var/lib/postgresql/restore

# 2. Укажите цель восстановления и источник WAL (postgresql.conf или postgresql.auto.conf)
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-10-03 14:31:00+03'
recovery_target_action = 'promote'

# 3. Создайте файл recovery.signal и запустите сервер с этим каталогом
touch /var/lib/postgresql/restore/recovery.signal

Сервер применяет записи WAL до целевого времени, после чего переходит к нормальной работе. Этот процесс следует опробовать в тестовой среде, а не впервые во время реального инцидента; точка отказа PITR чаще всего кроется в отсутствующем файле в архиве WAL, и выявить это способно только тестирование.

Политика хранения: как далеко в прошлое?

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

Практические заметки для больших баз данных

Параллельный запуск pg_dump (формат каталога и опция -j) сокращает время.
Для больших таблиц (логи, журналы событий) можно определить отдельную частоту бэкапов; не обязательно каждую ночь резервировать всю историю.
Бэкап следует выполнять не в часы пиковой нагрузки производственного сервера, а при низком трафике; для физического бэкапа этот эффект менее выражен.
Сжатие и шифрование бэкапов нагружают CPU; это должно учитываться при планировании ресурсов сервера.

Репликация — это не бэкап

Горячий бэкап (streaming replication) обеспечивает высокую доступность; однако случайно удаленная таблица за секунды отразится и на реплике. Репликация и резервное копирование дополняют друг друга, но не заменяют. Аналогично, снимки дисков (snapshots) обеспечивают быстрое восстановление, но для обеспечения согласованности они должны координироваться с базой данных и копироваться на другую площадку.

Резервное копирование в среде Docker

В PostgreSQL, работающем с Docker Compose, резервное копирование должно выполняться не изнутри контейнера, а с помощью отдельного контейнера бэкапов или плановой задачи на хост-машине; пока подключен том данных (volume), pg_dump работает через сеть контейнеров. Необходимо следить за совместимостью версий образа контейнера и формата бэкапа (версия pg_dump не должна быть старее версии базы данных).

# Пример: запланированный pg_dump в среде Compose (cron на хосте)
0 2 * * * docker exec app_db pg_dump -U app -Fc app | gpg --encrypt -r backup@ornek > /backups/app_$(date +%F).dump.gpg

Документирование

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

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