pgBackRest или Percona XtraBackup: что выгоднее и когда

MAATRIX

Если вы гуглите «pgBackRest или Percona XtraBackup», скорее всего, вы уже настраиваете бэкап базы данных на сервере и наткнулись на оба названия в одних и тех же статьях-рейтингах. Это сбивает с толку: кажется, что перед вами два конкурирующих решения одной задачи, и осталось только выбрать более быстрое или более экономное. На деле всё проще и одновременно менее очевидно — и мы разберём это честно, без притягивания за уши искусственного противостояния.

Это разные инструменты для разных СУБД

pgBackRest бэкапит PostgreSQL. Percona XtraBackup бэкапит MySQL и MariaDB (точнее, таблицы InnoDB/XtraDB). Они не читают чужой формат данных, не совместимы между собой и не конкурируют напрямую — как не конкурируют, например, зимняя резина и летняя: обе решают задачу «ехать», но подходят под разное дорожное покрытие.

Поэтому первый честный ответ на вопрос «что выгоднее» звучит так: выгоднее тот инструмент, который бэкапит именно вашу СУБД. Если у вас PostgreSQL — вопрос выбора между pgBackRest и XtraBackup не стоит физически, XtraBackup ваши данные просто не откроет. Если у вас MySQL или MariaDB — то же самое, только наоборот.

Реальный вопрос, который чаще всего стоит за такими запросами, — один из двух:

• вы выбираете стек для нового проекта («какую БД ставить и как её потом бэкапить») и сравниваете экосистемы PostgreSQL+pgBackRest и MySQL/MariaDB+XtraBackup в целом;
• вы уже администрируете и ту, и другую базу на разных серверах и хотите понять, насколько сопоставим у них уровень зрелости, ресурсоёмкость и удобство эксплуатации бэкапов.

Дальше разбираем оба сценария — сравнивая инструменты не «кто быстрее», а по архитектурным решениям, которые определяют, с чем вам жить дальше на проде.

Архитектура: как устроен бэкап у каждого

pgBackRest — специализированный инструмент именно под PostgreSQL, написан с нуля под эту СУБД и завязан на её WAL (Write-Ahead Log). Он умеет:

• полный, дифференциальный и инкрементальный бэкап;
• параллельное сжатие и передачу данных несколькими процессами (process-max);
• непрерывную архивацию WAL через archive-command, что даёт восстановление на произвольный момент времени;
• хранение нескольких «репозиториев» одновременно — например, локальную копию для быстрого восстановления и S3 для долгосрочного хранения.

Percona XtraBackup — форк идей InnoDB Hot Backup, физический бэкап поверх движка InnoDB/XtraDB. Он копирует файлы данных напрямую с диска, параллельно читая redo log, чтобы захватить транзакции, завершившиеся уже после старта копирования. Это классический hot backup без блокировки таблиц на запись (в отличие от mysqldump, который логически выгружает данные и на больших базах создаёт заметную нагрузку). XtraBackup умеет:

• полный и инкрементальный бэкап (на основе LSN — Log Sequence Number);
• сжатие (--compress, обычно qpress) и параллельные потоки копирования (--parallel);
• подготовку бэкапа (--prepare) — применение redo log к скопированным файлам перед восстановлением, аналог «докатки» транзакций.

Концептуально оба решают одну и ту же инженерную задачу — снять консистентный снапшот работающей базы без долгих блокировок — но делают это средствами, специфичными для внутреннего устройства своей СУБД. У PostgreSQL это WAL-архивирование и работа через pg_basebackup-протокол, у MySQL/MariaDB — прямое чтение файлов InnoDB и redo log. Перенести логику одного на другую базу нельзя, и это не недоработка авторов, а следствие того, что сами движки хранения устроены по-разному.

Производительность и потребление ресурсов

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

Практическое наблюдение: инкрементальные бэкапы у обоих инструментов кардинально снижают время и объём по сравнению с полным бэкапом на базах с невысокой долей изменений между запусками — это общий принцип physical incremental backup, а не уникальная фишка одного инструмента. На небольшом VPS (1–2 vCPU, 2–4 ГБ RAM) оба спокойно работают в дефолтной конфигурации на базах до нескольких десятков гигабайт; для более крупных баз стоит закладывать отдельный сервер под бэкап-репозиторий, чтобы I/O бэкапа не конкурировал с продовой нагрузкой. Мы отдельно считали, сколько RAM закладывать под pgBackRest и сколько под Percona XtraBackup — цифры там ориентировочные, но полезны как отправная точка при подборе плана сервера.

Восстановление и Point-in-Time Recovery

Оба инструмента поддерживают восстановление на произвольный момент времени (PITR), но механика различается.

pgBackRest опирается на непрерывный поток WAL: вы восстанавливаете последний полный/инкрементальный бэкап, а затем PostgreSQL сам докатывает WAL-сегменты до нужной секунды или до конкретного LSN/transaction ID:

# Восстановление кластера на момент времени
pgbackrest --stanza=main --type=time \
  --target="2026-08-28 10:15:00" restore

XtraBackup требует явного этапа «подготовки» перед восстановлением — применения redo log к скопированным файлам, а PITR на конкретную транзакцию делается через сочетание бэкапа и бинарных логов MySQL (binlog), которые нужно докатывать отдельной командой (mysqlbinlog) уже после восстановления файлового бэкапа:

# Подготовка полного бэкапа перед восстановлением
xtrabackup --prepare --target-dir=/backup/full

# Докатка бинлогов до нужной точки (отдельным шагом)
mysqlbinlog --stop-datetime="2026-08-28 10:15:00" \
  mysql-bin.000123 | mysql -u root -p

Разница ощутима именно в стрессовой ситуации: у pgBackRest PITR встроен как один сквозной механизм и настраивается один раз через archive-command, у XtraBackup это связка из двух независимых подсистем (файловый бэкап + binlog), которые нужно синхронизировать вручную. Это не значит, что PITR в MySQL/MariaDB ненадёжен — просто он требует более дисциплинированной настройки ротации и хранения бинлогов заранее, до того, как бэкап понадобится всерьёз.

Хранение бэкапов: локально, S3, ретеншн

pgBackRest из коробки поддерживает несколько типов репозитория, включая прямую запись в S3-совместимое хранилище, Azure Blob и GCS, без сторонних прослоек — конфигурация задаётся в pgbackrest.conf:

[main]
repo1-type=s3
repo1-s3-bucket=pg-backups
repo1-s3-endpoint=s3.example.com
repo1-s3-region=us-east-1
repo1-retention-full=4
repo1-retention-diff=7

XtraBackup сам по себе пишет бэкап в локальную директорию или на смонтированный том; для отправки в объектное хранилище обычно используют внешний скрипт или связку с rclone поверх готового архива. Это не критический недостаток — просто дополнительный шаг в пайплайне, который стоит учитывать при планировании cron-задачи.

По ретеншну оба поддерживают политики хранения (сколько полных/инкрементальных копий держать), но у pgBackRest это встроенная функция самого инструмента (repo1-retention-*), а у XtraBackup ротацию старых бэкапов чаще реализуют внешним скриптом или обвязкой вроде xtrabackup + cron + find по возрасту файлов.

Когда что выбирать: сценарии и чек-лист внедрения

Сведём выбор к практическим сценариям, а не абстрактному сравнению возможностей:

Базовый чек-лист внедрения для обоих инструментов на арендованном сервере:

1. Отдельный пользователь ОС и минимально необходимые права для процесса бэкапа (не root).
2. Бэкап-репозиторий — на отдельном диске или отдельном сервере, физически отделённом от источника данных.
3. Автоматизация через systemd-таймер или cron с логированием и алертом при ошибке.
4. Регулярная проверка целостности: pgbackrest check у pgBackRest, тестовый --prepare у XtraBackup.
5. Тестовое восстановление на отдельном сервере не реже раза в квартал — бэкап, который ни разу не восстанавливали, нельзя считать рабочим.

Для пошагового разворачивания с нуля у нас есть отдельные разборы установки обоих инструментов на Ubuntu 24.04 — команды расписаны от установки пакета до первого бэкапа, без сокращений.

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