Stage 6 Strapi smoke: Серверы Dell для виртуализации

27 апреля 2026 года репозиторий pgBackRest был архивирован. Дэвид Стил, создатель инструмента, объявил проект устаревшим из-за потери корпоративного спонсорства после продажи Crunchy Data [4, 81].

Если ваш продакшен использует последнюю стабильную версию v2.58.0 [23, 62], вы остались без патчей безопасности и исправлений багов. Инструмент написан на C [29, 63] — сложный код, который никто не будет чинить бесплатно. При следующем сбое WAL-архивации или изменении внутреннего формата PostgreSQL ваш бэкап может оказаться невосстановимым.

Вам не нужно переписывать архитектуру с нуля. Задача на один вечер: выбрать замену с живой поддержкой, которая умеет инкременты, S3 и шифрование, и перенести конфиги без потери истории.

Почему нельзя оставить pgBackRest как есть #

Отсутствие поддержки не означает, что бэкапы перестанут создаваться завтра. Это означает накопление риска.

pgBackRest сложен в модификации из-за языка реализации (C) [29]. У других инструментов есть корпоративные бэкеры: Barman поддерживает EnterpriseDB (EDB) [25, 66], pg_probackup — Postgres Pro [27, 40]. Эти компании выпускают патчи под новые версии PostgreSQL и закрывают уязвимости. У pgBackRest такого бэкера нет [38].

Исправление критической ошибки в C-коде без выделенной команды займёт месяцы. В продакшене это неприемлемо.

Критерии замены: что искать вместо pgBackRest #

Вам нужны физические бэкапы с поддержкой Point-in-Time Recovery (PITR). Логические дампы (pg_dump) не сохраняют WAL-сегменты и не позволяют восстановиться на конкретную секунду времени [37]. Их RPO (допустимая потеря данных) измеряется часами — интервалом между запусками cron [6]. Для продакшена это мало.

Сравниваем инструменты по трём параметрам:

Активный мейнтейнер. Гарантирует совместимость с будущими версиями PostgreSQL.
Тип инкрементов. File-level (копирование изменённых файлов) медленнее и занимает больше места, чем block-level (копирование изменённых блоков данных).
Архитектура. Нужен ли отдельный сервер для управления бэкапами.

pgBackRest поддерживал block-level инкременты [31]. Из оставшихся инструментов это умеет pg_probackup [33]. Barman работает только с file-level инкрементами [32].

Barman vs pg_probackup: выбор под инфраструктуру #

Barman (Python, EDB) #

Barman требует выделенного узла (barman-server) [43, 49]. Вы устанавливаете его на отдельную машину, и он централизованно управляет бэкапами десятков кластеров PostgreSQL [34].

Плюсы:

Удобное централизованное управление [34].
Активная поддержка от EDB [39]. Версия 3.18.0 вышла в марте 2026 года [24].
Написан на Python, проще читать и модифицировать скрипты при необходимости [26].

Минусы:

File-level инкременты [32]. Они объёмнее и дольше создаются, чем block-level.
Требует отдельного хоста. Для одиночной VDS это оверхед.

pg_probackup (C, Postgres Pro) #

Инструмент работает локально на сервере с базой или подключается удалённо. Выделенный менеджер не нужен.

Плюсы:

Block-level инкременты [33]. Меньший объём бэкапов и выше скорость создания.
Synthetic full backups [28]. Позволяют создать полный бэкап из инкрементов без нагрузки на продакшен-сервер.
Идеален для изолированных сред (VDS) или когда критична скорость восстановления (RTO) [3].

Минусы:

Менее удобен для централизованного управления сотней разрозненных кластеров по сравнению с Barman.

Альтернатива: WAL-G (Go) #

Если вам нужен простой CLI-инструмент для отправки WAL и базовых бэкапов в S3, смотрите на WAL-G [35, 56]. Он написан на Go, лёгкий и хорошо интегрируется в Kubernetes-стейтлесс окружения.

Нюанс: WAL-G не имеет встроенного управления политиками retention на уровне репозитория так, как это было в pgBackRest [46]. Вам придётся писать свои скрипты очистки старых файлов в S3. Также шифрование обычно реализуется на стороне клиента или хранилища, а не внутри инструмента [47].

Стратегия миграции: как не потерять историю #

Старые бэкапы pgBackRest нельзя восстановить через Barman или pg_probackup напрямую. Форматы несовместимы.

Запустите новый инструмент параллельно. Не отключайте pgBackRest сразу. Настройте Barman или pg_probackup на тот же кластер.
Сохраните старые WAL-архивы. Не удаляйте файлы из старого archive_command до момента, когда убедитесь, что новая система работает.
Проверьте archive_timeout. Установите значение 300 секунд (5 минут) в postgresql.conf [16]. Это гарантирует, что даже при низкой нагрузке WAL-сегменты будут архивироваться регулярно. Пробелы в WAL — главная причина неудачного PITR [44].
Тестовое восстановление. Разверните стенд. Сделайте полный бэкап новым инструментом. Имитируйте падение: удалите данные и восстановитесь через PITR. Сверьте count(*) в таблицах с продакшеном.

Только после успешного теста переключайте archive_command и cron-задачи на новый инструмент.

Чек-лист действий на сегодня #

Аудит. Проверьте версию pgBackRest. Если это v2.58.0 или ниже — поставьте задачу миграции в статус High Priority [62].
Выбор инструмента:
- Есть выделенный хост и много кластеров → ставьте Barman 3.18+ [24].
- Нужна максимальная скорость восстановления и блочные инкременты → ставьте pg_probackup [27].
- Нужен простой CLI для S3 без сложного менеджмента → смотрите на WAL-G [35].
Настройка. Установите archive_timeout = 300 в postgresql.conf [16].
Верификация. Сделайте тестовое восстановление из нового бэкапа на стенде. Убедитесь, что данные целы.