Резервное копирование PostgreSQL на VDS — это не «раз в ночь pg_dump и спокойно». В проде почти всегда нужны: быстрые инкременты, непрерывная доставка WAL (continuous archiving), восстановление до точки во времени (PITR), вменяемая retention policy и регулярный restore test.
На практике чаще всего выбирают один из трёх инструментов: pgBackRest, WAL-G или Barman. Все они умеют связку «physical backup + WAL archive», но отличаются философией, операционными рисками и тем, насколько удобно поддерживать предсказуемый процесс восстановления.
Ниже — разбор с позиции администратора/DevOps: что важно на одиночной VDS, в схеме с репозиторием, при хранении в S3-совместимом объектном хранилище, с ретеншном, шифрованием и проверками восстановления.
Базовые понятия: без них сравнение бессмысленно
Чтобы не сравнивать «яблоки с апельсинами», зафиксируем термины, на которых строится любая рабочая схема бэкапов PostgreSQL.
Base backup: full vs incremental
Full (полный) бэкап — копия всех необходимых файлов кластера PostgreSQL. Он надёжен, но дорог по месту и времени, а на маленькой VDS может дать неприятный пик I/O.
Incremental (инкрементальный) — копирует только изменения относительно предыдущего бэкапа. Это сильно снижает нагрузку и объём хранилища, но повышает требования к дисциплине: цепочки инкрементов нужно обслуживать, а удаление «не того» бэкапа способно сделать невозможным восстановление.
Continuous archiving и PITR
Continuous archiving — постоянная отправка WAL-сегментов в архив (локально или в объектное хранилище). Это фундамент для PITR (Point-In-Time Recovery): вы восстанавливаете последний base backup и «доигрываете» WAL до нужного момента времени.
Самая частая причина провала PITR — не инструмент, а «дыры» в WAL: архивирование не работало час, закончилось место, отвалилась сеть, а алерта не было.
RPO/RTO: что реально зависит от инструмента
RPO (сколько данных можно потерять) почти всегда определяется непрерывностью WAL-архивации и тем, как быстро вы замечаете сбой в архивировании.
RTO (как быстро восстановиться) зависит от скорости восстановления base backup, наличия инкрементов/диффов, пропускной способности диска/сети и от того, насколько «безошибочен» ваш runbook восстановления.
Кто есть кто: философия pgBackRest, WAL-G и Barman
pgBackRest
pgBackRest — «комбайн» для физических бэкапов PostgreSQL с упором на надёжность: инкременты/диффы, проверки целостности, параллелизм, компрессию и шифрование. Поддерживает локальные репозитории и объектные (включая S3-совместимые).
Практическая идея: pgBackRest старается быть единым центром управления base backup и WAL с понятным ретеншном и safety-проверками.
WAL-G
WAL-G — «облачный» по духу инструмент (наследник WAL-E). Сильная сторона — удобная доставка WAL и base backup в объектные хранилища (S3/GCS/Azure и S3-совместимые). Его часто выбирают, когда ставка на объектное хранилище и минимальное локальное состояние.
Практическая идея: WAL-G даёт простой путь «PostgreSQL → объекты в бакете», но ретеншн, валидации и восстановление лучше заранее оформить как процедуру (и прогнать в тесте), а не держать в голове.
Barman
Barman (Backup and Recovery Manager) исторически мыслит моделью «есть barman-server и есть один или много PostgreSQL-серверов». Он силён в централизованном управлении, каталогизации, сценариях для нескольких кластеров и в предсказуемых процессах восстановления.
Практическая идея: Barman особенно удобен, когда вы готовы выделить отдельный узел под бэкапы/каталог и хотите «операторскую» модель управления.
Если хотите отдельно углубиться в механику PITR (что происходит при восстановлении и где чаще ошибаются), держите подробный разбор: PITR в PostgreSQL: как работает восстановление по WAL.
Сравнение по требованиям: инкременты, PITR, S3, ретеншн, шифрование
1) Полные и инкрементальные бэкапы
pgBackRest — один из самых удобных вариантов, если вы хотите регулярно делать full + diff/incr и при этом держать процесс предсказуемым. Параллелизм и встроенные проверки хорошо помогают на VDS, где важно не «убить» диск и уложиться в окно обслуживания.
WAL-G на практике часто используют как «base backup + WAL в объектное хранилище». Инкрементальные сценарии возможны, но если вы целитесь именно в управляемые цепочки инкрементов с прозрачной политикой хранения, pgBackRest обычно проще эксплуатировать.
Barman больше про процесс и каталог: типичный паттерн — регулярные бэкапы (часто полные по расписанию) плюс непрерывный архив WAL, с централизованной политикой на barman-сервере.
2) PITR и continuous archiving
Все три решают задачу continuous archiving и дают PITR. Отличие — в том, насколько инструмент помогает вам не ошибиться в рутине: что считать «последним валидным» бэкапом, где искать нужные WAL и как проверять целостность цепочки.
pgBackRest: чаще выигрывает за счёт целостной модели «бэкапы + WAL + retention + команды info/check». Хорошо для runbook в стиле «одна точка правды».
WAL-G: удобен, когда WAL «льются» прямо в бакет. Но мониторинг «дыр» и дисциплина префиксов/политик очистки становятся критичнее.
Barman: в схемах с несколькими PostgreSQL-серверами может быть самым «организованным»: каталог, отчёты, единая политика и понятные роли доступа.
3) S3-совместимое хранилище как основное
Если вы заранее знаете, что основное хранилище — объектное (S3 или S3-совместимое), обычно расклад такой:
WAL-G: самый прямолинейный путь «WAL и base backup в бакет». Хорошо ложится в модель immutable/версионирования объектов.
pgBackRest: тоже умеет объектные репозитории, но часто даёт больше контроля внутри самого инструмента (в том числе по ретеншну и шифрованию).
Barman: нередко предполагает отдельный barman-сервер с локальным хранилищем и уже поверх — выгрузку/вторую копию в объектное хранилище. Это дополнительный слой, но он может ускорить восстановление и снижает зависимость от сети в момент аварии.
Если под PostgreSQL нужен отдельный сервер с предсказуемыми дисками и сетью, проще всего начинать с подходящего тарифа VDS: бэкапы и PITR гораздо стабильнее, когда ресурсы не «впритык».
4) Retention policy: удержание без сюрпризов
Retention policy — это не «оставить 7 файлов». Вам нужно ответить на вопросы, которые напрямую влияют на риск и стоимость:
Сколько дней/недель вы реально обязаны уметь восстановить?
Нужны ли «якорные» полные бэкапы (например, еженедельные) и частые инкременты?
Сколько держать WAL-архив относительно base backup, чтобы PITR был возможен для всего нужного окна?
Как защищаться от случайного удаления: раздельные ключи/права, versioning, Object Lock (если используется)?
pgBackRest обычно удобнее тем, что retention встроен как часть механики репозитория: задаёте правила удержания для full/diff/incr и отдельно для архива WAL. Это снижает риск несогласованной очистки («WAL удалили раньше, чем бэкап» или наоборот).
WAL-G чаще требует более строгой дисциплины: чистка старых объектов должна быть продумана и обязательно прогнана на стенде. Ошибки в ретеншне в объектном хранилище неприятны тем, что «удаление прошло», а реальность вскрывается только при восстановлении, когда не хватает одного сегмента WAL.
Barman хорош, когда retention — часть централизованного процесса для нескольких кластеров: единая политика, единые отчёты, единые расписания.
5) Encryption: шифрование и ключи
Шифрование — это не только «включить опцию». Нужно заранее решить, где живут ключи, кто имеет доступ, и что произойдёт в сценарии DR.
pgBackRest: часто выбирают за встроенное шифрование репозитория и управляемость, без обвязки из нескольких слоёв.
WAL-G: обычно шифрование организуют на стороне клиента/хранилища (в зависимости от требований). Это гибко, но добавляет места, где можно ошибиться: переменные окружения, права доступа к бакету, совместимость процедуры restore.
Barman: на практике шифрование часто делается «вокруг» (шифрование диска/тома, шифрование передачи, политики доступа), главное — чтобы ключи были отделены от бэкапов и доступны в аварийной процедуре.
Операционные критерии на VDS: что решает в реальной жизни
Нагрузка на диск и окно бэкапа
На VDS критично не устроить I/O-шторм и не выжечь место под WAL/временные файлы. Инкременты и параллельная обработка помогают, но ещё важнее предсказуемость. pgBackRest обычно проще настроить так, чтобы бэкапы были «быстрыми и регулярными». WAL-G при объектном хранилище часто сильнее упирается в сеть и производительность компрессии.
Архитектура: один сервер или отдельный backup-host
Есть два типовых паттерна эксплуатации:
Один сервер PostgreSQL, репозиторий рядом: часто удобнее pgBackRest; если принципиально хранить всё в объектном хранилище — WAL-G.
Отдельный backup-host (ещё одна VDS) + опционально объектное хранилище как вторая копия: тут Barman раскрывается сильнее за счёт каталога и централизованного процесса.
Восстановление: удобство важнее «красоты» бэкапа
При аварии вы будете думать не про проценты компрессии, а про ответы на три вопроса: какая последняя гарантированно пригодная точка восстановления, где лежит base backup и где лежат WAL нужного интервала, сколько времени займёт поднятие.
В этом смысле pgBackRest часто радует «самодокументируемостью» репозитория и командами статуса/инфо. Barman хорош отчётностью и каталогом. WAL-G требует, чтобы ваш процесс (runbook) был действительно отточен и проверен.
Restore test: как перестать верить бэкапам на слово
Restore test — обязательная часть системы резервного копирования. Без регулярной проверки вы не знаете, работает ли PITR, хватает ли WAL, корректны ли права на объектное хранилище, не истекли ли ключи шифрования.
Практичный минимальный план для VDS:
Поднимайте отдельный sandbox (вторая ВМ или временный инстанс) и восстанавливайте туда свежий base backup.
Проверяйте запуск PostgreSQL и выполнение контрольного запроса (например, наличие ожидаемых таблиц/данных).
Раз в N дней делайте именно PITR на конкретный момент времени (например, «на 02:37 вчера»), чтобы проверить непрерывность WAL.
Логируйте длительность восстановления: это ваш реальный RTO.
Единственный «настоящий» бэкап — тот, который вы хотя бы раз успешно восстановили в условиях, близких к аварии.
Отдельно полезно иметь короткий внутренний чек-лист «что делаем, если восстановление упёрлось в WAL». Например: проверить, что в postgresql.conf корректно настроены archive_mode и archive_command, а на диске не копится очередь WAL из-за ошибок отправки.
Короткая матрица выбора: что поставить на вашу VDS
Выбирайте pgBackRest, если…
Вам нужны удобные full/diff/incr и сильная retention policy «из коробки».
Важно встроенное шифрование и проверки целостности репозитория.
Вы хотите максимально предсказуемую эксплуатацию на одном сервере или в простой схеме с репозиторием.
Выбирайте WAL-G, если…
Ваш основной сценарий — бэкапы PostgreSQL прямо в S3-совместимое объектное хранилище и минимум локального состояния.
Вы готовы инвестировать время в строгий runbook, мониторинг архивации WAL и тесты восстановления.
Вы опираетесь на возможности бакета (versioning, lifecycle, объектные политики доступа).
Выбирайте Barman, если…
Нужен централизованный менеджмент бэкапов для нескольких PostgreSQL-инстансов.
Вы готовы держать отдельный barman-сервер (часто это отдельная VDS под бэкапы).
Важны отчёты, каталогизация и управляемость процессов восстановления.
Если бэкапы содержат персональные данные или коммерческую тайну, имеет смысл заранее выбрать и оформить SSL-сертификаты для админок/панелей и внутренних сервисов, через которые вы управляете доступом и процессами восстановления.
Типичные ошибки (и как их избежать)
Ошибка 1: WAL архивируется, но не мониторится
Нужны метрики/алерты: «последний успешно загруженный WAL», «ошибки архивации», «сколько WAL накопилось локально», «свободное место». Иначе PITR однажды окажется невозможным.
Ошибка 2: retention чистит «не то»
Опаснее всего — потерять WAL, нужный для восстановления конкретного base backup. Любые операции очистки должны быть протестированы на стенде и привязаны к реальному графику бэкапов.
Ошибка 3: шифрование включили, а ключи не продумали
Если ключи лежат на том же сервере и с теми же правами, что и бэкапы, при компрометации вы теряете смысл шифрования. Если ключи потеряны — вы теряете восстановление. Нужен баланс: отдельное хранение, понятный доступ в DR и регламент ротации.
Ошибка 4: restore test «когда-нибудь потом»
Планируйте restore test как задачу эксплуатации: по расписанию, с фиксацией времени восстановления и с понятным критерием успеха. Минимум — тест обычного восстановления, регулярно — тест PITR.
Итог
pgBackRest, WAL-G и Barman решают одну задачу — сделать физический бэкап PostgreSQL и обеспечить PITR через continuous archiving. Разница в том, насколько инструмент помогает вам не ошибиться в деталях: ретеншне, целостности, процедуре восстановления и повседневной эксплуатации.
Если нужен универсальный инструмент для VDS с сильными инкрементами и понятной политикой хранения — чаще всего побеждает pgBackRest. Если ставка на объектное хранилище и вы строите «бэкапы как объекты» — WAL-G даёт прямой путь. Если хотите централизованный бэкап-узел и управляемые процессы для нескольких инстансов — смотрите в сторону Barman.
И что бы вы ни выбрали: проверяйте восстановление. Иначе бэкап остаётся гипотезой.
Чтобы разнести оффер и изображение: сначала — смысловой вывод. На практике для выделенного узла под бэкапы и тестовые восстановления удобнее иметь отдельные ресурсы и запас по диску/сети, особенно если PITR нужен с минимальным RPO.
