Резервное копирование PostgreSQL: pgBackRest, Barman, WAL-G

Резервное копирование и восстановление PostgreSQL, часть 5 — сравнение enterprise-инструментов: pgBackRest, Barman, WAL-G

pg_basebackup и архивирование WAL оказываются недостаточными в крупных production-средах, где нужны параллельная обработка, политики хранения, шифрование, каталог резервных копий и интеграция с облачным хранилищем. pgBackRest силён блочными инкрементальными копиями и delta-восстановлением для крупных OLTP-нагрузок свыше 500 ГБ; Barman выделяется централизованным управлением множеством инстансов для команд DBA; WAL-G предлагает самый простой путь к объектному хранилищу для Kubernetes и cloud-native окружений. При этом отправной точкой при выборе любого из них должна быть стратегия резервного копирования, построенная на RPO/RTO, правиле 3-2-1 и регулярных учениях по восстановлению, а вовсе не таблица сравнения возможностей.

Обзор серии

  • Часть 1 — основы и стратегия резервного копирования

  • Часть 2 — логическое резервное копирование: pg_dump и pg_dumpall на практике

  • Часть 3 — физическое резервное копирование: pg_basebackup и архивирование WAL

  • Часть 4 — руководство по внедрению PITR (Point-in-Time Recovery)

  • Часть 5 — сравнение enterprise-инструментов: pgBackRest vs Barman vs WAL-G (текущая)

  • Часть 6 — автоматизация и мониторинг резервного копирования, учения по восстановлению (готовится)

1. Введение — пределы встроенных инструментов

В частях 3 и 4 мы разбирали, как настроить PITR с помощью pg_basebackup и архивирования WAL. Эта связка надёжна, но по мере роста production-масштаба она быстро упирается в свой потолок.

Практические ограничения pg_basebackup
- Нет параллелизма → время копирования разрастается после нескольких сотен ГБ
- Нет инкрементальных или дифференциальных копий (нативный инкремент в v17 ещё на ранней стадии)
- Нет управления политиками хранения
- Нет шифрования
- Нет централизованного управления множеством серверов
- Нет каталога или истории резервных копий
- Нет прямой поддержки облачного объектного хранилища

Именно этот пробел закрывают сторонние enterprise-инструменты резервного копирования. В этой части мы подробно сравним три наиболее распространённых инструмента в экосистеме PostgreSQL по состоянию на 2026 год — pgBackRest, Barman и WAL-G.

2. Три инструмента с высоты птичьего полёта

Характеристика pgBackRest Barman WAL-G

Язык

C

Python

Go

Разработчик

Crunchy Data (open source)

EnterpriseDB (open source)

Citus Data → Microsoft (open source)

Лицензия

MIT

GPL v3

Apache 2.0

Актуальная версия

2.58 (2026.01)

3.18 (2026.03)

v3.0.8 (2026.01)

Полная копия

да

да

да

Дифференциальная копия

да

да (на уровне файлов)

да (delta)

Инкрементальная копия

да (на уровне блоков)

да (на уровне файлов)

да (delta)

Параллельная обработка

да (копирование и восстановление)

ограниченно

да (сжатие/передача)

Встроенное сжатие

да (gzip, lz4, zstd, bz2)

да (gzip, lz4, zstd)

да (lz4, zstd, brotli)

Встроенное шифрование

да (AES-256-CBC)

да

да (AES-256-CTR)

Облачное хранилище

да (S3, GCS, Azure)

да (barman-cloud)

да (S3, GCS, Azure, Swift)

Управление множеством серверов

ограниченно (возможно, но распределённо)

да (централизованно)

ограниченно (каждый сервер отдельно)

Каталог резервных копий

да

да

ограниченно (только список)

Сложность настройки

высокая

средняя

низкая

Основное назначение

крупные БД, высокая производительность

централизованное управление множеством серверов

cloud-native, Kubernetes

3. pgBackRest — де-факто стандарт для высоконагруженного production

3.1 Обзор

По состоянию на 2026 год pgBackRest стал де-факто стандартом для резервного копирования production-инстансов PostgreSQL. Написанный на C, он обеспечивает отличную производительность и надёжно работает даже на масштабе в несколько терабайт. Он также входит в поставку Percona Distribution for PostgreSQL.

3.2 Ключевые возможности

Блочное инкрементальное копирование — это возможность, которая ярче всего отличает pgBackRest от конкурентов. Поскольку копируются только изменённые блоки по 8 КБ, а не целые файлы, размер и длительность копирования для крупных баз можно радикально сократить. Опция --delta применяет тот же принцип при восстановлении, восстанавливая только изменённые блоки и тем самым ускоряя процесс.

Концепция Stanza управляет каждым кластером PostgreSQL независимо. Одна конфигурация pgBackRest может охватывать несколько кластеров.

Поддержка Multi-Repository позволяет одновременно копировать на локальный диск и в S3, реализуя стратегию 3-2-1 одним инструментом.

3.3 Установка и базовая настройка

# Ubuntu/Debian
sudo apt install pgbackrest
# RHEL/CentOS
sudo dnf install pgbackrest
# /etc/pgbackrest/pgbackrest.conf
[global]
# Local backup repository
repo1-path=/var/lib/pgbackrest
# S3 repository (optional: for multi-repository setup)
repo2-type=s3
repo2-s3-bucket=my-pg-backups
repo2-s3-region=ap-northeast-2
repo2-s3-key=AKIAIOSFODNN7EXAMPLE
repo2-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo2-s3-endpoint=s3.amazonaws.com
repo2-path=/pgbackrest
# Retention policy
repo1-retention-full=4 # keep 4 full backups
repo1-retention-diff=14 # keep 14 differential backups
# Compression (zstd recommended: balanced speed and ratio)
compress-type=zstd
compress-level=3
# Encryption
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=MyStrongEncryptionPassphrase
# Parallel processes (half of CPU core count recommended)
process-max=4
# Logging
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest
[main] # stanza name
pg1-path=/var/lib/postgresql/17/main
pg1-user=postgres
pg1-port=5432
# Add to postgresql.conf
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
wal_level = replica
Примечание

Замечание по безопасности: избегайте хранения учётных данных S3 открытым текстом внутри pgbackrest.conf. Предпочтительнее использовать IAM-роль EC2 или подход на основе переменных окружения.

3.4 Основные команды

# Initialize stanza (one-time)
sudo -u postgres pgbackrest --stanza=main stanza-create
# Validate configuration
sudo -u postgres pgbackrest --stanza=main check
# Full backup
sudo -u postgres pgbackrest --stanza=main --type=full backup
# Differential backup (changes since last full backup)
sudo -u postgres pgbackrest --stanza=main --type=diff backup
# Incremental backup (changes since last backup)
sudo -u postgres pgbackrest --stanza=main --type=incr backup
# List backups
sudo -u postgres pgbackrest --stanza=main info
# Restore to latest backup
sudo -u postgres pgbackrest --stanza=main restore
# PITR to a specific point in time
sudo -u postgres pgbackrest --stanza=main restore \
--type=time \
--target="2026-04-14 14:34:59+09" \
--target-action=promote
# Delta restore (restore only changed files → faster)
sudo -u postgres pgbackrest --stanza=main restore --delta
# Verify WAL archive
sudo -u postgres pgbackrest --stanza=main check \
--archive-timeout=60

3.5 Пример расписания резервного копирования

# crontab -u postgres -e
# Every Sunday at 1 AM: full backup
0 1 * * 0 pgbackrest --stanza=main --type=full backup
# Every day at 1 AM except Sunday: differential backup
0 1 * * 1-6 pgbackrest --stanza=main --type=diff backup
# Every hour on the hour: incremental backup
0 * * * * pgbackrest --stanza=main --type=incr backup

3.6 Идеальные сценарии

  • Крупные production-среды с размером БД свыше 500 ГБ

  • Критически важные системы, которым нужно блочное инкрементальное копирование для минимизации RPO

  • Гибридные конфигурации on-premises и облачного хранилища

  • Развёртывания, интегрированные с профессиональной поддержкой PostgreSQL (Percona, Crunchy Data)

4. Barman — лидер централизованного управления множеством серверов

4.1 Обзор

Barman (Backup and Recovery Manager) — это инструмент резервного копирования на Python, разрабатываемый и сопровождаемый компанией EnterpriseDB (EDB). Его определяющая черта — централизованное управление множеством инстансов PostgreSQL с выделенного сервера резервного копирования. Это преимущество ярко проявляется в enterprise-средах, где эксплуатируется много серверов БД.

4.2 Ключевые возможности

Централизованная архитектура: выделенный сервер Barman собирает и управляет резервными копиями со всех серверов PostgreSQL. Команды DBA получают единую точку контроля для наблюдения и управления состоянием резервного копирования по всей инфраструктуре.

Режим Streaming-Only: начиная с Barman 2.0, потоковая передача через pg_basebackup и pg_receivewal является рекомендуемым режимом по умолчанию. Он работает без SSH, а pg_receivewal передаёт WAL в реальном времени ещё до завершения каждого сегмента WAL, снижая риск потери WAL.

Команда barman check: встроенная команда проверки работоспособности за один запуск проверяет всё состояние окружения резервного копирования, делая повседневную эксплуатацию удобнее.

4.3 Архитектура

Выделенный сервер Barman подключается к каждому серверу PostgreSQL, собирает базовые копии и потоки WAL и хранит их централизованно под единой политикой хранения.

4.4 Установка и базовая настройка

# Install on Barman server
sudo apt install barman barman-cli
# Install client on PostgreSQL servers
sudo apt install barman-cli
# Barman server: /etc/barman.conf (global config)
[barman]
barman_user = barman
barman_home = /var/lib/barman
log_file = /var/log/barman/barman.log
log_level = INFO
compression = gzip
# /etc/barman.d/pg-primary.conf (per-server config)
[pg-primary]
description = "Primary PostgreSQL Server"
# PostgreSQL connection info
conninfo = host=pg-primary user=barman dbname=postgres
# Streaming replication connection info
streaming_conninfo = host=pg-primary user=streaming_barman
# Streaming mode settings
backup_method = postgres # use pg_basebackup
streaming_archiver = on # WAL streaming via pg_receivewal
slot_name = barman # replication slot name
create_slot = auto # auto-create slot
# Retention policy
retention_policy = RECOVERY WINDOW OF 7 DAYS
minimum_redundancy = 1
# Compression
compression = gzip
-- Create Barman-dedicated users on the PostgreSQL server
CREATE USER barman WITH SUPERUSER PASSWORD 'barman_pass';
CREATE USER streaming_barman WITH REPLICATION PASSWORD 'streaming_pass';

4.5 Основные команды

# Full server health check
barman check pg-primary
# Sample output:
# Server pg-primary:
# PostgreSQL: OK
# is_superuser: OK
# streaming replication: OK
# wal_level: OK
# replication slot: OK
# archive_mode: OK
# continuous archiving: OK
# Run a backup
barman backup pg-primary
# List backups
barman list-backup pg-primary
# Show backup details
barman show-backup pg-primary latest
# PITR to a specific point in time
barman recover pg-primary latest \
/var/lib/postgresql/17/main \
--target-time "2026-04-14 14:34:59" \
--remote-ssh-command "ssh postgres@pg-primary"
# Recover to a specific transaction ID
barman recover pg-primary latest \
/var/lib/postgresql/17/main \
--target-xid 1234567 \
--remote-ssh-command "ssh postgres@pg-primary"
# Delete a backup
barman delete pg-primary 20260414T010000
# Clean up WAL archive (apply retention policy)
barman cron

4.6 Идеальные сценарии

  • Среды, где с одного сервера резервного копирования управляют пятью и более серверами PostgreSQL

  • Организации с командой DBA и требованиями соответствия enterprise-уровня

  • Традиционная on-premises или гибридная инфраструктура

  • Развёртывания, требующие коммерческой поддержки EDB

5. WAL-G — выбор для cloud-native

5.1 Обзор

WAL-G — это cloud-first инструмент резервного копирования, написанный на Go, разработанный Citus Data (ныне Microsoft) и являющийся преемником WAL-E. Он оптимизирован для прямой отправки резервных копий в объектное хранилище — AWS S3, GCS, Azure Blob Storage и другие.

Его настройка относительно проста, и он поддерживает несколько СУБД, включая MySQL, MongoDB и Redis наряду с PostgreSQL, что делает его естественным выбором для сред со смешанными БД. Он широко используется в Kubernetes- и контейнерных развёртываниях; ряд Kubernetes-операторов PostgreSQL, таких как Zalando Postgres Operator, применяют WAL-G как инструмент резервного копирования по умолчанию.

5.2 Ключевые возможности

Прямое облачное архивирование: установка archive_command в wal-g wal-push %p отправляет файлы WAL напрямую в объектное хранилище без прохождения через отдельный сервер. Выделенный сервер резервного копирования не нужен.

Delta-копирование: переменная окружения WALG_DELTA_MAX_STEPS управляет тем, сколько delta-копий допускается между полными копиями. Delta-копии хранят только изменённые файлы, экономя место.

Параллельное сжатие и загрузка: поддерживаются многоядерное параллельное сжатие и multipart-загрузка в S3, что удерживает высокую скорость даже при крупных прогонах копирования.

5.3 Установка и базовая настройка

# Download the latest binary from GitHub Releases
WAL_G_VERSION="v3.0.8"
curl -L "https://github.com/wal-g/wal-g/releases/download/${WAL_G_VERSION}/wal-g-pg-ubuntu-20.04-amd64.tar.gz" \
-o /tmp/wal-g.tar.gz
tar -xzf /tmp/wal-g.tar.gz -C /usr/local/bin/
chmod +x /usr/local/bin/wal-g
# Environment variable config file (envdir approach recommended)
mkdir -p /etc/wal-g.d/env
# AWS S3 settings
echo "s3://my-pg-backups/wal-g" > /etc/wal-g.d/env/WALG_S3_PREFIX
echo "ap-northeast-2" > /etc/wal-g.d/env/AWS_REGION
echo "AKIAIOSFODNN7EXAMPLE" > /etc/wal-g.d/env/AWS_ACCESS_KEY_ID
echo "wJalrXUtnFEMI..." > /etc/wal-g.d/env/AWS_SECRET_ACCESS_KEY
# Compression method (zstd or brotli recommended)
echo "zstd" > /etc/wal-g.d/env/WALG_COMPRESSION_METHOD
# Max delta steps between full backups (required for delta backups to work)
echo "5" > /etc/wal-g.d/env/WALG_DELTA_MAX_STEPS
# Parallel upload/download count
echo "4" > /etc/wal-g.d/env/WALG_UPLOAD_CONCURRENCY
echo "4" > /etc/wal-g.d/env/WALG_DOWNLOAD_CONCURRENCY
# PGDATA path
echo "/var/lib/postgresql/17/main" > /etc/wal-g.d/env/PGDATA
chown -R postgres:postgres /etc/wal-g.d/env
chmod 600 /etc/wal-g.d/env/*
# Add to postgresql.conf
archive_mode = on
archive_command = 'envdir /etc/wal-g.d/env wal-g wal-push %p'
wal_level = replica

5.4 Основные команды

# Full base backup (pushed directly to S3)
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g backup-push /var/lib/postgresql/17/main
# Delta backup (changed files only)
# WALG_DELTA_MAX_STEPS must be set for this to take effect
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g backup-push --full=false /var/lib/postgresql/17/main
# List backups
sudo -u postgres envdir /etc/wal-g.d/env wal-g backup-list
# Restore to latest backup
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g backup-fetch /var/lib/postgresql/17/main LATEST
# Restore to a specific backup by name
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g backup-fetch /var/lib/postgresql/17/main base_20260414T010000Z
# Apply retention policy (keep last 7 full backups)
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g delete retain FULL 7 --confirm
# Verify WAL archive integrity
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g wal-verify integrity timeline
# postgresql.conf: PITR recovery settings
restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
recovery_target_action = 'pause'

5.5 Идеальные сценарии

  • Развёртывания PostgreSQL на базе Kubernetes или контейнеров

  • Cloud-native инфраструктура в публичных облаках AWS, GCP или Azure

  • Команды со смешанными стеками БД (PostgreSQL наряду с MySQL, MongoDB и т. д.)

  • Команды, которым нужна система резервного копирования, целиком построенная на объектном хранилище, без выделенного сервера

  • Небольшие и средние DevOps-команды, для которых приоритетна простота настройки

6. Глубокое сравнение — четыре решающих различия

6.1 Метод копирования: на уровне блоков vs на уровне файлов

Это самое технически значимое различие.

pgBackRest (block-level incremental)
Full backup: 1 TB
Incremental backup: only changed 8 KB blocks → can reach single-digit GB
Barman / WAL-G (file-level incremental)
Full backup: 1 TB
Incremental backup: entire changed files → limited benefit when files are large

В OLTP-паттернах, где записи концентрируются на нескольких крупных таблицах, блочное инкрементальное копирование pgBackRest значительно эффективнее.

6.2 Скорость восстановления (delta-восстановление)

Опция --delta в pgBackRest сравнивает текущий каталог данных с резервной копией и восстанавливает только изменённые файлы или блоки. Когда большинство файлов нетронуты — например, после логической ошибки или изолированного повреждения таблицы — это гораздо быстрее полного восстановления.

6.3 Архитектура: централизованная vs распределённая

Barman: централизованный мониторинг и единое применение политик, но сам сервер резервного копирования может стать единой точкой отказа.

pgBackRest: поддерживает более гибкую топологию, но конфигурация усложняется при управлении множеством серверов.

WAL-G: самая простая инфраструктура, максимально близкая к serverless-модели, но единый межсерверный мониторинг затруднён.

6.4 Операционная сложность vs возможности

Low <------------------------------------> High
WAL-G Barman pgBackRest
(simple setup) (moderate) (feature-rich, complex)

Правильный выбор зависит от экспертизы вашей команды в PostgreSQL и операционной зрелости. Инструмент, напичканный возможностями, становится обузой, если команда не может надёжно его эксплуатировать.

7. Руководство по выбору под ситуацию

DB < 100 GB, small/mid-sized team, cloud environment
-> WAL-G (simple setup, direct S3 integration)
DB 100 GB-1 TB, single server, PITR required
-> pgBackRest (balanced performance and features)
DB > 1 TB, OLTP, minimize RPO
-> pgBackRest + block-level incremental backup
5+ PostgreSQL servers, centralized management required
-> Barman (optimized for centralized management)
Kubernetes / container environment
-> WAL-G (native integration with Zalando Operator, etc.)
Mixed DB stack (PostgreSQL + MySQL, etc.)
-> WAL-G (multi-database support)
Enterprise compliance, EDB support required
-> Barman

8. PITR-команды восстановления бок о бок

Все три инструмента поддерживают PITR, но структура их команд различается. Знание этих различий заранее избавляет от путаницы во время инцидента.

# pgBackRest: PITR to a specific point in time
sudo -u postgres pgbackrest --stanza=main restore \
--type=time \
--target="2026-04-14 14:34:59+09" \
--target-action=promote \
--delta # delta restore for faster recovery
# Barman: PITR to a specific point in time (requires remote SSH)
sudo -u barman barman recover pg-primary latest \
/var/lib/postgresql/17/main \
--target-time "2026-04-14 14:34:59" \
--remote-ssh-command "ssh postgres@pg-primary"
# WAL-G: restore base backup, then set PITR parameters in postgresql.conf
sudo -u postgres envdir /etc/wal-g.d/env \
wal-g backup-fetch /var/lib/postgresql/17/main LATEST
# Then add to postgresql.auto.conf:
# restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
# recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
# recovery_target_action = 'promote'
# touch recovery.signal -> restart PostgreSQL

9. Универсальные лучшие практики — независимо от выбранного инструмента

Эти принципы применимы независимо от того, какой инструмент вы выберете.

(1) Всегда проверяйте резервные копии после их завершения

# pgBackRest
pgbackrest --stanza=main verify
# WAL-G
wal-g wal-verify integrity timeline
# Barman
barman check pg-primary

(2) Задайте чёткую политику хранения

Неограниченное хранение приводит к раздуванию хранилища; слишком короткое окно делает невозможным восстановление после логических ошибок, обнаруженных с опозданием. Установите минимум 30 дней или следуйте требованиям соответствия вашей организации.

(3) Проводите реальные учения по восстановлению по регулярному графику

Каким бы способным ни был инструмент, команды, не знакомые с процедурой восстановления, будут ошибаться под давлением. Планируйте как минимум одно полноценное учение по восстановлению в квартал.

(4) Подключите оповещения к мониторингу резервного копирования

Тихо провалившееся резервное копирование — самая опасная ситуация из всех. Направляйте уведомления об успехе/провале копирования в канал, за которым ваша команда действительно следит, — Slack, email, PagerDuty или аналог.

10. Заключение — стратегия важнее инструмента

pgBackRest, Barman и WAL-G — все они превосходные инструменты. Любой из них при правильной настройке и эксплуатации может стать основой надёжной системы резервного копирования.

Но кое-что важнее выбора инструмента.

Инструмент резервного копирования — это средство исполнения стратегии. Инструмент не может заменить саму стратегию.

Определите свои цели RPO/RTO, следуйте правилу 3-2-1 и регулярно проверяйте свою способность к восстановлению. Выбирайте инструмент, который лучше всего исполняет эту стратегию, а не наоборот.

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

Источники

  • Официальная документация pgBackRest

  • Официальная документация Barman (v3.18)

  • WAL-G на GitHub

  • Top Open-Source Postgres Backup Solutions in 2026 — Bytebase (январь 2026)

  • PostgreSQL Backup Tools Comparison — DEV Community (январь 2026)

  • Automating Backups and DR: pgBackRest vs Barman — Severalnines (ноябрь 2025)

  • Best PostgreSQL Backup Solutions in 2026 — PostgresGUI (февраль 2026)

  • pgBackRest File Bundling and Block Incremental Backup — Crunchy Data

  • PostgreSQL Backup and Recovery Management using Barman — Stormatics (февраль 2026)

© 2026 meganuke