pgBackRest и barman одинаково умеют складывать WAL-архив и бэкапы в S3, но оба выросли из эпохи, когда основным хранилищем была локальная файловая система, а объектное хранилище — опциональный репозиторий поверх. WAL-G спроектирован наоборот: он написан на Go и с первого дня целится именно в object storage как основной репозиторий, без промежуточного слоя абстракций под POSIX-пути.
Базовый цикл — те же два архивных хука, что и у pg_basebackup, только команды вызывают wal-g:
# postgresql.conf
archive_mode = on
archive_command = 'wal-g wal-push %p'
restore_command = 'wal-g wal-fetch %f %p'
Сам полный бэкап кластера — одна команда, путь к PGDATA и дальше всё по переменным окружения:
wal-g backup-push $PGDATA
# список сделанных бэкапов с размерами и временем
wal-g backup-list -v
# восстановление конкретного (или LATEST) бэкапа
wal-g backup-fetch $PGDATA LATEST
Конфигурация хранилища тоже через переменные окружения, без отдельного конфиг-файла с секциями под каждый репозиторий, как у pgBackRest:
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export WALG_S3_PREFIX="s3://my-bucket/pg-backups"
Ретеншн задаётся отдельной командой delete — либо по количеству, либо по дате, либо комбинацией обоих условий, и без флага --confirm команда просто покажет, что было бы удалено:
wal-g delete retain 3
wal-g delete before backup_name
Из практических отличий: WAL-G умеет backup-fetch с опцией --reverse-unpack, разворачивающей дельта-бэкапы в обратном порядке (от самого свежего к базовому), что на больших кластерах с длинной цепочкой инкрементов ощутимо экономит время по сравнению с последовательной накаткой вперёд. Поддержка не ограничена PostgreSQL — тот же бинарник умеет бэкапить MySQL, MongoDB, Redis и ещё несколько СУБД с одной и той же логикой архивирования в object storage, что удобно, если в инфраструктуре не только Postgres.
#postgresql #backup