Резервное копирование PostgreSQL: pg_dump или pg_probackup

Администраторы обычно приходят к этой теме одним из двух путей: либо база выросла и ночной дамп перестал успевать, либо восстановление после сбоя заняло полдня и стало ясно, что «у нас есть pg_dump» — это ещё не стратегия. Разберём все три уровня резервного копирования PostgreSQL с рабочими командами: логический дамп, физическую копию с восстановлением на момент времени и pg_probackup — штатную утилиту СУБД Postgres Pro, которая закрывает жизненный цикл копий целиком.

Короткий ответ: какой инструмент выбрать

Практический ориентир: база до десятка гигабайт и допустима потеря дня работы — достаточно pg_dump по расписанию. Продуктивная база, которую нужно уметь вернуть на конкретную минуту, — физический бэкап с WAL-архивом. Много баз, большие объёмы, требования к сроку восстановления — pg_probackup.

pg_dump: когда логической копии достаточно

pg_dump выгружает одну базу в виде набора SQL-команд, которые заново создают все объекты и данные. Дамп не мешает работе: пока идёт выгрузка, пользователи продолжают читать и писать, а копия получается согласованной на момент запуска.

Базовые команды по документации PostgreSQL:

pg_dump -Fc mydb > db.dump          # копия в сжатом формате для pg_restore
pg_dump -Fd mydb -j 5 -f dumpdir    # формат каталога, выгрузка в 5 потоков
pg_restore -d newdb db.dump         # восстановление в чистую базу
pg_dump -t mytab mydb > table.sql   # выгрузка одной таблицы

Роли и табличные пространства принадлежат кластеру, а не базе, поэтому pg_dump их не выгружает — для них есть pg_dumpall. Рабочая связка: дамп каждой базы в своём формате плюс pg_dumpall -g для глобальных объектов.

Ограничения тоже честные. Восстановление дампа — это выполнение всех SQL-команд заново с перестроением индексов: на сотнях гигабайт процесс растягивается на часы. И главное — вернуться можно только на момент запуска pg_dump. Всё, что записано после, теряется. Если это неприемлемо, нужен следующий уровень.

Физический бэкап и PITR: pg_basebackup и WAL-архив

Физическая копия — это файлы кластера как есть, плюс журнал предзаписи (WAL), в который PostgreSQL пишет каждое изменение. Пара «базовая копия + непрерывный архив WAL» позволяет восстановить кластер на любой момент времени — это и есть PITR (point-in-time recovery).

Включите архивирование WAL в postgresql.conf:

wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

И снимайте базовую копию:

pg_basebackup -D /backup/base -Ft -z -P   # сжатые tar-файлы, с прогрессом

Начиная с PostgreSQL 17 pg_basebackup умеет и инкрементальные копии: сервер ведёт сводки WAL, параметр --incremental принимает манифест предыдущей копии, а перед восстановлением цепочка склеивается утилитой pg_combinebackup. Следить за цепочками, сроками хранения и целостностью копий при этом придётся самостоятельно — встроенного учёта взаимосвязей между копиями в PostgreSQL нет, документация прямо предупреждает об этом.

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

pg_probackup: что добавляет Postgres Pro

pg_probackup 3 поставляется в составе СУБД Postgres Pro Standard и Enterprise и заменяет самодельную обвязку вокруг pg_basebackup системой управления копиями: каталог с метаинформацией, инкременты, проверка целостности, политики хранения, параллельные потоки. Типовой сценарий:

pg_probackup3 init -B /backup
pg_probackup3 add-instance -B /backup -D /var/lib/pgpro/data --instance=main
pg_probackup3 backup -B /backup --instance=main -b FULL --stream    # полная копия
pg_probackup3 backup -B /backup --instance=main -b PTRACK --stream  # инкремент
pg_probackup3 show -B /backup                                       # каталог копий
pg_probackup3 validate -B /backup                                   # проверка целостности

Механизм PTRACK отслеживает изменённые страницы прямо в момент записи, поэтому инкрементальная копия не читает всю базу заново. При восстановлении работает обратная оптимизация: режим -I CHECKSUM заменяет в существующем каталоге данных только повреждённые и изменённые страницы вместо полного копирования. Политика хранения задаётся один раз, дальше утилита сама чистит устаревшие копии и ненужные сегменты WAL:

pg_probackup3 set-config -B /backup --instance=main --retention-redundancy=2 --retention-window=7
pg_probackup3 retention -B /backup --instance=main --delete-expired --delete-wal

Восстановление на момент времени — одной командой, без ручной правки конфигурации восстановления:

pg_probackup3 restore -B /backup --instance=main --recovery-target-time="2026-08-14 09:00:00+03" --recovery-target-action=promote

Третья версия добавила то, чего не было ни в pg_basebackup, ни в старом pg_probackup: копия хранится единым файлом, а не россыпью тысяч мелких; одна версия утилиты обслуживает разные версии СУБД; копировать и восстанавливать можно отдельную базу данных, а не только кластер целиком; цепочки инкрементов объединяются командой merge.

В

к этому добавляется уровень, который вендор называет работой с базой «прямо из резервной копии»: команда fuse монтирует копию как виртуальный каталог PGDATA, и экземпляр СУБД запускается на ней в режиме чтения — без полного восстановления. Так можно достать случайно удалённые данные через pg_dump со вчерашней копии, проверить состояние базы на нужную дату или построить отчёт, пока продуктив работает. Enterprise же открывает хранение копий в S3-совместимых хранилищах (данные передаются в бакет напрямую, без промежуточного диска), поддержку сжатой файловой системы CFS и ленточных устройств. Обе редакции при этом совместимы с российскими системами резервного копирования — Кибер Бэкапом и RuBackup.

Стратегия: RPO и RTO на пальцах

Прежде чем выбирать инструмент, ответьте на два вопроса. RPO (recovery point objective) — сколько данных не жалко потерять: час работы операторов? день? RTO (recovery time objective) — сколько бизнес переживёт простоя, пока база восстанавливается. Дальше арифметика простая.

Ночной pg_dump — это RPO до 24 часов и RTO в часы на заметной базе. Базовая копия с WAL-архивом сжимает RPO до минут, но RTO зависит от того, сколько WAL придётся воспроизвести с момента последней полной копии. Инкременты pg_probackup позволяют делать копии чаще и быстрее, инкрементальное восстановление сокращает RTO, а FUSE в Enterprise даёт доступ к данным из копии за минуты — ещё до того, как полное восстановление завершится.

Бэкап баз 1С на PostgreSQL

Перевод 1С на PostgreSQL сам по себе снимает главный страх файлового режима — «файл базы данных повреждён»; если вы пришли сюда именно с этой ошибкой, начните со статьи Ошибка СУБД в 1С: что делать.

База 1С в PostgreSQL — обычная база кластера, и для СУБД работают все описанные инструменты. Специфика в другом: баз обычно много (рабочая, копии для разработки, тестовые), они большие, и разработчикам регулярно нужна свежая копия отдельной базы, а не кластера целиком. Ровно этот сценарий вендор закрывает в pg_probackup: резервное копирование и восстановление отдельных баз, по оценке Postgres Professional, в несколько раз ускоряет получение копий баз для задач 1С, а PITR позволяет откатить последствия ошибочной обработки на минуту до её запуска.

Для 1С у вендора есть отдельный продукт —

— сборка Postgres Pro Enterprise с пресетом настроек под нагрузку 1С и лицензированием по конфигурации сервера, а не по ядрам. Как выбрать между бесплатной сборкой и коммерческой версией — разобрали в статье PostgreSQL для 1С.

Сколько стоит pg_probackup

Отдельной лицензии на pg_probackup не существует — утилита входит в поставку СУБД Postgres Pro Standard и Enterprise. Лицензируются сами СУБД, по ядрам процессора: сервер на 8 ядер — это 8 лицензий, минимальная покупка — 2 ядра. Лицензия бессрочная, первый год гарантийной поддержки включён.

Standard закрывает базовый сценарий: инкременты PTRACK, проверка копий, политики хранения, копии отдельных баз единым файлом. Enterprise добавляет запуск базы из копии через FUSE, хранение в S3 и ленты — плюс возможности самой СУБД уровня отказоустойчивого кластера BiHA. Полное сравнение редакций — в разборе Postgres Pro и PostgreSQL: в чём разница.

Рекомендуем в статье Лицензия СУБД Postgres Pro Standard на 1 ядро x86-64

PPT-86-LIC

195 006 ₽ НДС не облагается (ст. 149 НК РФ) — позиция в реестре российского ПО

Расчёт PDF В корзину В корзине Подробнее →

Как купить на юрлицо

СУБД Postgres Pro включена в реестр российского ПО, поэтому лицензии не облагаются НДС и проходят в проекты с требованием импортозамещения. Работаем с юрлицами по безналичному расчёту: счёт, договор, закрывающие документы, комплект для тендерной документации. Отгрузка электронная.

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

Частые вопросы