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 открытым текстом внутри |
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)