pgBackRest для PostgreSQL: инкрементные бэкапы, репозитории и восстановление

Разбираем, как настроить надёжные бэкапы PostgreSQL с pgBackRest: включаем архивирование WAL, запускаем full/diff/inc, выносим репозиторий на отдельный хост или в S3 и отрабатываем восстановление, включая PITR. Дадим политику хранения, расписание и проверку целостности.

Инструкции
23 окт, 2025
Время на чтение: ~15 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

pgBackRest для PostgreSQL: инкрементные бэкапы, репозитории и восстановление

Зачем pgBackRest и чем он лучше «просто» pg_basebackup

pgBackRest — зрелый инструмент бэкапа для PostgreSQL, который решает ключевые задачи эксплуатации: быстрые инкрементальные копии, проверка целостности, эффективная дедупликация на уровне блоков, параллелизм, сжатие и прозрачная работа с удалённым репозиторием (через SSH) и объектными хранилищами (S3-совместимые бекенды). В отличие от простого pg_basebackup, pgBackRest строит цепочку бэкапов (full/diff/inc), управляет архивом WAL и автоматизирует восстановление до точки во времени (PITR) без ручной магии.

Если у вас уже есть PostgreSQL в продакшене, вам понадобятся:

полный бэкап и регулярные дифференциальные/инкрементальные за короткое окно;
вынос репозитория с сервера БД (SSH или S3) ради отказоустойчивости;
отработанная процедура восстановления: от полного до PITR;
понятная политика хранения и автоматическое «смывание» старых цепочек.

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

Как устроены типы бэкапов и репозитории

pgBackRest оперирует тремя типами копий:

Full — полная база. От неё зависят все дальнейшие копии;
Diff — изменения относительно последнего полного бэкапа;
Inc — изменения относительно последнего бэкапа любого типа (full/diff/inc).

Репозиторий может быть:

локальным (на том же сервере — быстро, но риски в случае потери узла);
удалённым по SSH (на другом сервере/хранилище);
S3-совместимым объектным хранилищем (гибко, экономно, легко масштабировать).

Для построения полной стратегии посмотрите также материал с разбором WAL и восстановлением до точки: PITR и WAL: как работает восстановление в PostgreSQL.

Терминал: запуск pgBackRest backup и вывод info

Установка: Debian/Ubuntu и RHEL/AlmaLinux

Пакеты есть в репозиториях дистрибутивов. Устанавливаем на сервер БД; если будет удалённый репозиторий, то и там тоже.

# Debian/Ubuntu
sudo apt update
sudo apt install pgbackrest

# RHEL/AlmaLinux/Rocky
sudo dnf install pgbackrest

Создадим каталоги (если пакет не создал) и дадим права пользователю PostgreSQL:

sudo mkdir -p /var/lib/pgbackrest /var/log/pgbackrest /etc/pgbackrest/conf.d /var/spool/pgbackrest
sudo chown -R postgres:postgres /var/lib/pgbackrest /var/log/pgbackrest /var/spool/pgbackrest
sudo chmod 750 /var/lib/pgbackrest /var/log/pgbackrest /var/spool/pgbackrest

Базовая конфигурация: локальный репозиторий

Минимальный рабочий сценарий — хранить бэкапы локально, чтобы проверить цепочку и процедуру восстановления. Далее вынесем их на отдельный хост и в S3.

Конфиг pgBackRest

Файл /etc/pgbackrest/pgbackrest.conf:

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
compress-type=zst
compress-level=3
start-fast=y
process-max=4
spool-path=/var/spool/pgbackrest
log-level-console=info
log-level-file=detail

[main]
pc1-path=/var/lib/postgresql/16/main
pg1-port=5432
archive-async=y

Пояснения:

retention — хранить 4 полных копии и дифференциалы за 14 дней;
compress-type=zst — современное сжатие, баланс скорости и экономии;
process-max — параллелизм потоков копирования;
start-fast=y — сокращает «паузы» на старте бэкапа;
archive-async=y — асинхронная отправка WAL, снижает задержки в транзакциях.

Включаем архивирование WAL в PostgreSQL

В postgresql.conf добавьте или скорректируйте параметры (путь зависит от дистрибутива и версии):

wal_level=replica
archive_mode=on
archive_command='pgbackrest --stanza=main archive-push %p'
archive_timeout=60s
max_wal_senders=10
wal_compression=on

Для включения wal_level и archive_mode потребуется перезапуск экземпляра PostgreSQL:

sudo systemctl restart postgresql

Инициализация stanza и первый бэкап

Stanza — это логическое имя инсталляции БД в терминах pgBackRest. Создаём stanza и делаем полный бэкап:

sudo -u postgres pgbackrest --stanza=main --log-level-console=info stanza-create
sudo -u postgres pgbackrest --stanza=main --type=full backup
sudo -u postgres pgbackrest info

Проверьте, что в выводе info появился набор с типом full, и растут архивы WAL.

Дифференциальные и инкрементальные бэкапы

Схема, которая хорошо себя показывает на средних нагрузках:

раз в неделю — полный бэкап;
ежедневно (кроме дня полного) — дифференциальный;
ежечасно — инкрементальный для плотных RPO.

Пример расписания в /etc/cron.d/pgbackrest (пользователь postgres):

# Полный бэкап по воскресеньям в 02:05
5 2 * * 0 postgres pgbackrest --stanza=main --type=full backup
# Дифференциальный в остальные дни в 02:05
5 2 * * 1-6 postgres pgbackrest --stanza=main --type=diff backup
# Инкрементальный каждый час в 15 минут
15 * * * * postgres pgbackrest --stanza=main --type=inc backup
# Периодический expire для очистки старых цепочек
0 4 * * * postgres pgbackrest --stanza=main expire

Команда expire удаляет бэкапы и связанные WAL вне политики хранения.

Репозиторий на отдельном хосте по SSH

Вынос репозитория на отдельный сервер повышает отказоустойчивость. Устанавливаем pgBackRest на оба узла. На хосте-репозитории создаём пользователя и каталог хранилища:

# На repository-хосте
sudo useradd --system --home /var/lib/pgbackrest --shell /bin/bash pgbackrest
sudo mkdir -p /var/lib/pgbackrest /var/log/pgbackrest
sudo chown -R pgbackrest:pgbackrest /var/lib/pgbackrest /var/log/pgbackrest
sudo chmod 750 /var/lib/pgbackrest /var/log/pgbackrest

Генерируем ключи на хосте БД и добавляем на repository-хост:

# На DB-хосте
sudo -u postgres ssh-keygen -t ed25519 -f /var/lib/postgresql/.ssh/id_ed25519 -N ""
# Скопировать ключ на repo-хост в пользователя pgbackrest
sudo -u postgres ssh-copy-id -i /var/lib/postgresql/.ssh/id_ed25519.pub pgbackrest@repo-host

Конфиг на DB-хосте (/etc/pgbackrest/pgbackrest.conf):

[global]
repo1-host=repo-host
repo1-host-user=pgbackrest
repo1-path=/var/lib/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
compress-type=zst
process-max=4
spool-path=/var/spool/pgbackrest
log-level-console=info

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432
archive-async=y

Конфиг на repository-хосте (/etc/pgbackrest/pgbackrest.conf):

[global]
repo1-path=/var/lib/pgbackrest
log-level-console=info

После этого (на DB-хосте) повторно выполните stanza-create и бэкап — теперь данные будут уходить по SSH на отдельный узел. Если своего сервера нет, удобно поднять хранилище на VDS с диском под репозиторий и ограниченным доступом по SSH.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

S3-репозиторий: экономия места и «бесконечный» рост

Для хранения в S3-совместимом хранилище достаточно переключить тип репозитория и задать параметры доступа. pgBackRest сам шифрует/сжимает архив, поддерживает префиксы и параллелизм. Пример:

[global]
repo1-type=s3
repo1-s3-bucket=my-pgbackups
repo1-s3-region=eu-central-1
repo1-s3-endpoint=s3.example.com
repo1-s3-uri-style=path
repo1-path=/pg
repo1-retention-full=4
repo1-retention-diff=14
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=ChangeMeToLongRandomSecret
compress-type=zst
process-max=8
spool-path=/var/spool/pgbackrest

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432
archive-async=y

Учётные данные добавьте в среду сервиса или файл конфигурации (по политикам безопасности вашей платформы):

# Пример переменных окружения для службы
export PGBACKREST_REPO1_S3_KEY=AKIA...REDACTED
export PGBACKREST_REPO1_S3_KEY_SECRET=verysecret...

Шифрование (repo1-cipher-type) защитит бэкапы при хранении и транспортировке, даже если бакет недоступен извне. Про организацию S3-бэкапов и экономию места есть отдельный разбор: S3-бэкапы: сравнение подходов на практике.

Восстановление: от полного до PITR

Отработайте процедуру восстановления заранее. Общая последовательность для восстановления в тот же инстанс:

Остановить PostgreSQL.
Освободить/переименовать текущий каталог данных.
Выполнить restore (с --delta, чтобы переиспользовать неизменившиеся файлы, если каталог не пустой).
Запустить PostgreSQL и убедиться, что идёт реплей WAL.

# Остановка
sudo systemctl stop postgresql
# Сохранить старые данные
sudo mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main.broken.$(date +%F)
# Восстановление последнего доступного бэкапа
sudo -u postgres pgbackrest --stanza=main --delta restore
# Старт
sudo systemctl start postgresql

Восстановление до точки во времени (PITR) требует времени/метки транзакции. Укажите --type=time и параметр --target:

sudo systemctl stop postgresql
sudo -u postgres pgbackrest --stanza=main --type=time --target="2025-10-01 14:23:00+03" --delta --target-action=promote restore
sudo systemctl start postgresql

pgBackRest сам пропишет команду для получения WAL и нужные флаги восстановления. Следите за логами PostgreSQL: при успешном PITR сервер перейдёт в обычный режим после применения необходимых WAL.

Последовательность PITR: точка восстановления и реплей WAL в PostgreSQL

Восстановление стендбая

Чтобы развернуть реплику, используйте --type=standby и задайте параметры подключения к мастеру через --recovery-option:

sudo systemctl stop postgresql
sudo -u postgres pgbackrest --stanza=main --type=standby --recovery-option="primary_conninfo=host=master-db port=5432 user=replicator password=secret" --delta restore
sudo systemctl start postgresql

В результате будет создан standby.signal, и узел сразу подключится к источнику. Обновите параметры безопасности и сеть для доступа только с нужных адресов.

Проверка целостности и обслуживание

pgbackrest check — проверка конфигурации, доступа, наличия каталога WAL и прав;
pgbackrest info — список наборов бэкапов и их состояние;
pgbackrest verify — верификация содержимого в репозитории (нагружает диск/сеть);
pgbackrest expire — очистка старых наборов по политике хранения.

После обновления версии PostgreSQL не забудьте stanza-upgrade, чтобы pgBackRest обновил метаданные инсталляции:

sudo -u postgres pgbackrest --stanza=main stanza-upgrade

Оптимизация: скорость, размер, конкурентность

Параллелизм: process-max повышает скорость, но помните о дисковой подсистеме и сетевом канале.
Сжатие: zst обычно даёт лучший компромисс; для «тяжёлых» таблиц с уже сжатыми данными снижайте compress-level.
Delta: --delta при восстановлении ускоряет процесс и экономит трафик.
WAL: wal_compression=on уменьшает размер журнала; archive_timeout не ставьте слишком маленьким, чтобы не плодить мелкие файлы.

Табличные пространства, большие объекты и детали

pgBackRest корректно сохраняет и восстанавливает табличные пространства, символические ссылки и большие объекты. Если указаны нестандартные пути, убедитесь, что у процесса PostgreSQL хватает прав на целевые каталоги при восстановлении. При необходимости используйте опции восстановления, такие как --link-all, чтобы управлять поведением ссылок.

Безопасность репозитория

Минимизируйте доступ: отдельный системный пользователь на repository-хосте, ограниченные ключи SSH, минимум прав в бакете S3.
Шифруйте бэкапы: repo1-cipher-type=aes-256-cbc и длинный случайный repo1-cipher-pass.
Изолируйте трафик: межсетевые экраны по источникам/портам, мониторинг аномалий.
Резервируйте метаданные: экспортируйте конфиги и ключи шифрования в надёжное место (офлайн).

Типичные ошибки и как их диагностировать

WAL не архивируется: проверьте archive_mode=on, корректность archive_command, права пользователя, логи pgBackRest.
Нет доступа к каталогу: пользователь процесса должен владеть путями pg1-path, repo1-path, spool-path.
Медленно и «горячий» диск: снизьте process-max, проверьте конкурентные I/O, вынесите репозиторий на другой диск/узел.
Растёт хранилище: проверьте, что expire выполняется, нет ли долгоживущих репликационных слотов, удерживающих WAL.
PITR ушёл не в то время: чётко фиксируйте часовой пояс и используйте точные метки времени из логов/аудита.

Пример рабочей политики

Для средненагруженной базы:

еженедельный полный бэкап;
ежедневные дифференциалы;
инкрементальные ежечасно;
срок хранения 4 полноценных цепочек и дифференциалов за 14 дней;
репозиторий вне узла БД (SSH или S3);
раз в квартал — тестовое восстановление на изолированную площадку.

Чек-лист внедрения

Установить pgBackRest на нужные узлы.
Включить WAL-архивирование и перезапустить PostgreSQL.
Настроить pgbackrest.conf и создать stanza.
Выполнить первый полный бэкап и убедиться, что пишутся WAL.
Настроить расписание full/diff/inc и expire.
Вынос репозитория (SSH или S3) и контроль прав доступа.
Проверка восстановления: полное и PITR на тестовой площадке.
Мониторинг: info, размер репозитория, успешность задач.

Итоги

pgBackRest закрывает ключевые потребности эксплуатации PostgreSQL: быстрые и компактные инкрементальные бэкапы, надёжное хранение в S3 или на отдельном хосте, предсказуемое восстановление и PITR. Настройте архивирование WAL, отработайте сценарии восстановления, автоматизируйте расписания и проверяйте целостность — и у вас будет понятная, воспроизводимая стратегия резервного копирования.

Поделиться статьей