Как установить и настроить pgBackRest на VPS

MAATRIX

Если база растёт, а pg_dump по ночам уже не укладывается в окно бэкапа или съедает всё I/O на проде, значит пора переходить на промышленный инструмент. pgBackRest делает полные, дифференциальные и инкрементальные копии PostgreSQL с параллельным сжатием и восстановлением на конкретный момент времени — и делает это на порядок быстрее логического дампа. Ниже — рабочая настройка с нуля на VPS: от установки до первого восстановления.

Что такое pgBackRest и зачем он нужен

pgBackRest — open-source утилита для физического бэкапа PostgreSQL, написанная C-разработчиками из Crunchy Data специально для промышленной эксплуатации. В отличие от pg_dump (логический дамп, блокирует консистентность через снимок транзакции и восстанавливается медленно через INSERT/COPY) pgBackRest копирует файлы кластера на уровне блоков и WAL-журналы, поэтому:

• полный бэкап многотерабайтной базы снимается за минуты, а не часы, за счёт многопоточного копирования и сжатия (process-max);
• инкрементальные и дифференциальные копии переносят только изменившиеся блоки — экономия места и времени в разы по сравнению с ежедневным полным дампом;
• восстановление возможно на любую точку времени (PITR) — до конкретной транзакции, LSN или таймстампа;
• есть встроенная проверка целостности (page checksums), шифрование бэкапов и параллельное восстановление;
• бэкапы можно слать сразу в S3-совместимое хранилище, Azure Blob или GCS, без промежуточного диска.

Из минусов — это не для «одного pg_dump раз в неделю»: требует отдельного планирования репозитория, понимания WAL-архивирования и чуть более сложной начальной настройки, чем логический бэкап. Если у вас база на пару гигабайт и простых требований к RPO — возможно, хватит и штатного pg_dump/pg_basebackup. Если база растёт, а простой на восстановление критичен — pgBackRest окупается быстро.

Отдельный VPS под роль бэкап-сервера (репозиторий pgBackRest, отдельно от прод-базы) — разумная схема: изоляция от нагрузки, независимый диск, возможность держать несколько поколений бэкапов без риска забить место на боевом сервере.

Установка pgBackRest

Далее — Ubuntu 24.04 LTS, PostgreSQL 16 (актуальная связка на конец августа 2026). Для AlmaLinux/RHEL шаги аналогичны, меняются только имена пакетов и путь к репозиторию PGDG.

Ставим сам pgBackRest — он есть в стандартных репозиториях Ubuntu, но версия там обычно отстаёт на 1-2 релиза, поэтому надёжнее подключить репозиторий PostgreSQL (PGDG), где пакет обновляется синхронно с сервером БД:

sudo apt install -y curl ca-certificates gnupg
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/postgresql.gpg
echo "deb [signed-by=/usr/share/keyrings/postgresql.gpg] \
http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list
sudo apt update
sudo apt install -y pgbackrest postgresql-16

Проверяем версию — на момент написания актуальна ветка 2.5x:

pgbackrest version

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

sudo mkdir -p /etc/pgbackrest /var/log/pgbackrest /var/lib/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest /var/lib/pgbackrest
sudo chmod 750 /var/log/pgbackrest /var/lib/pgbackrest

Если репозиторий бэкапов будет на этом же сервере (что не рекомендуется для прод-нагрузки, но нормально для теста или небольшого проекта), каталог /var/lib/pgbackrest и станет репозиторием. Для отдельного бэкап-сервера pgBackRest ставится и там же, доступ идёт по SSH с ключами без пароля.

Настройка PostgreSQL для работы с pgBackRest

pgBackRest требует включённого WAL-архивирования — без него не получится ни PITR, ни консистентных инкрементальных копий. Правим postgresql.conf (обычно /etc/postgresql/16/main/postgresql.conf):

listen_addresses = 'localhost'
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 60
max_wal_senders = 3

archive_timeout = 60 заставляет PostgreSQL переключать WAL-сегмент не реже раза в минуту, даже при низкой нагрузке — иначе на малоактивной базе точка восстановления может отставать на часы. Для боевой базы с высоким RPO-требованием ставьте меньше, но помните — это дополнительная запись на диск.

Если бэкап-сервер отдельный, добавьте в pg_hba.conf доступ для пользователя, от имени которого pgBackRest подключается (по умолчанию — postgres):

local   all   postgres                trust

Либо, если pgBackRest ходит по TCP с отдельного хоста — строка с адресом бэкап-сервера и scram-sha-256. Перезапускаем PostgreSQL:

sudo systemctl restart postgresql

Тонкая настройка shared_buffers, checkpoint_completion_target и прочих параметров производительности — отдельная тема, она разобрана в статье про тюнинг PostgreSQL; для самого pgBackRest эти параметры прямого значения не имеют.

Конфигурация pgbackrest.conf

Основной конфиг — /etc/pgbackrest/pgbackrest.conf. Минимальный рабочий вариант для локального репозитория (бэкапы на том же сервере, но на отдельном диске):

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

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

[main] — это имя «станцы» (stanza), логической единицы бэкапа для одного кластера PostgreSQL. process-max=4 включает параллельное копирование и сжатие в 4 потока — на VPS с 4 vCPU это разумный старт, при большем числе ядер можно поднять. compress-type=zst (Zstandard) даёт лучшее соотношение скорость/степень сжатия, чем gz по умолчанию в старых версиях.

Для репозитория в S3-совместимом хранилище (например, отдельный бакет под бэкапы) конфиг репозитория меняется так:

[global]
repo1-type=s3
repo1-s3-bucket=my-backup-bucket
repo1-s3-endpoint=s3.example.com
repo1-s3-region=ru-1
repo1-s3-key=YOUR_ACCESS_KEY
repo1-s3-key-secret=YOUR_SECRET_KEY
repo1-path=/pgbackrest
repo1-retention-full=4

Ключи доступа лучше не хранить прямо в конфиге на проде — используйте переменные окружения (PGBACKREST_REPO1_S3_KEY и подобные) или ограниченный по правам файл /etc/pgbackrest/pgbackrest.conf (600, владелец postgres).

Инициализируем станцу и проверяем конфигурацию:

sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main check

Команда check проверяет доступность WAL-архивации и корректность подключения к кластеру — если она падает, сначала разбираться нужно тут, а не переходить к первому бэкапу.

Первый бэкап и типы копий

Первый бэкап всегда полный (full) — от него зависят все последующие инкрементальные:

sudo -u postgres pgbackrest --stanza=main --type=full backup

На базе в десятки гигабайт с process-max=4 это займёт минуты, не часы — параллелизм и сжатие на лету дают заметный выигрыш перед однопоточным pg_basebackup. Точные цифры сильно зависят от диска, сети до репозитория и объёма данных — не берите чужие бенчмарки как ориентир для своего сервера, лучше замерить на реальных данных.

Дальше — инкрементальные копии (переносят только блоки, изменившиеся с последнего бэкапа любого типа):

sudo -u postgres pgbackrest --stanza=main --type=incr backup

Или дифференциальные (изменения с последнего *полного* бэкапа — крупнее инкрементальных, но восстановление быстрее, так как нужно применить меньше цепочек):

sudo -u postgres pgbackrest --stanza=main --type=diff backup

Типичная схема: полный бэкап раз в неделю, дифференциальный раз в сутки, инкрементальный — несколько раз в день на активной базе. Посмотреть список всех бэкапов и их размеры:

sudo -u postgres pgbackrest --stanza=main info

Команда покажет цепочку full → diff → incr, объём каждой копии и то, насколько бэкап-сервер отстаёт по последнему заархивированному WAL — это удобный индикатор здоровья всей схемы.

Восстановление из бэкапа

Для восстановления сначала останавливаем PostgreSQL и очищаем каталог данных (или используем --delta для восстановления поверх существующих файлов — быстрее на большом кластере):

sudo systemctl stop postgresql
sudo -u postgres pgbackrest --stanza=main --delta restore
sudo systemctl start postgresql

Восстановление на конкретный момент времени (PITR) — например, на момент за 10 минут до ошибочного DROP TABLE:

sudo -u postgres pgbackrest --stanza=main \
  --type=time --target="2026-08-30 14:25:00+03" \
  --delta restore

Аналогично можно восстанавливать по имени именованной точки (--type=name, если вы заранее ставили pg_create_restore_point) или по конкретному LSN (--type=lsn) — последнее полезно, когда точное время инцидента неизвестно, но известна позиция в журнале транзакций из логов приложения. После восстановления PostgreSQL поднимается в режиме recovery и автоматически проигрывает WAL до указанной точки, затем переключается в обычный режим — это стоит проверить по логам (recovery.signal исчезнет, сервер начнёт принимать запросы на запись).

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

Автоматизация, retention и мониторинг

Ротацию бэкапов настраивает сам pgBackRest через параметры retention в конфиге — repo1-retention-full=2 означает «хранить 2 последних полных бэкапа и всё, что от них зависит», всё более старое удаляется автоматически при следующем полном бэкапе. Для diff-копий — repo1-retention-diff.

Расписание — обычный cron от пользователя postgres:

sudo crontab -u postgres -e

# полный бэкап по воскресеньям в 02:00
0 2 * * 0 pgbackrest --stanza=main --type=full backup
# дифференциальный ежедневно в 02:00, кроме воскресенья
0 2 * * 1-6 pgbackrest --stanza=main --type=diff backup
# инкрементальный каждые 4 часа
0 */4 * * * pgbackrest --stanza=main --type=incr backup

Для мониторинга полезны две вещи: регулярный pgbackrest info --output=json в связке с любой системой мониторинга (Zabbix, Prometheus через текстовый экспортер) — он отдаёт статус последнего бэкапа и WAL-задержку машиночитаемо; и периодическая проверка check, которая ловит проблему с архивированием WAL раньше, чем она превратится в дыру в цепочке восстановления. Если вы уже настраивали репликацию PostgreSQL, обратите внимание — pgBackRest умеет бэкапить и со standby-реплики (backup-standby=y), снимая нагрузку с мастера.

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