Настройка pgBackRest: где ломается бэкап PostgreSQL
pgBackRest настраивается за пару часов, и копии начинают появляться по расписанию. Но переполнение репозитория ломает процесс тихо: объём растёт быстрее политики хранения, и когда место заканчивается, перестают приниматься и полные копии, и журнальные сегменты. Сбой резервного копирования всплывает не по тревоге, а по факту отсутствия свежей копии — обычно во время аварии.
Отдельная ловушка — разрыв в архивации журналов. Архивный процесс может отставать или встать после перезапуска сервера, тогда как полные копии продолжают создаваться по расписанию. Формально копии есть, но восстановление на нужную точку невозможно: между последней копией и инцидентом остаётся дыра, которую нечем закрыть.
Ещё один источник ошибки восстановления из копии — расхождение расписаний. Копирование, архивация журналов и очистка старых копий живут в разных таймерах; когда окно копирования перекрывается с окном очистки, политика хранения удаляет опорную копию, от которой зависят инкрементальные. Восстановление падает с сообщением об отсутствующем сегменте ровно тогда, когда копия нужнее всего.
Непроверенная копия — самый дорогой класс отказов: отчёты об успешном завершении не доказывают, что кластер поднимется из этих данных. Повреждённый сегмент, несовпадение версий, нехватка прав на каталог восстановления вскрываются только на реальном прогоне на отдельном стенде.
Разбираем, как это закрывается: контроль места и сроков хранения в репозитории, мониторинг архивации журналов, согласованные окна заданий и восстановление с проверкой целостности.
Восстановление к нужной точке и проверка целостности копий
Резервная копия полезна ровно настолько, насколько точно известно, на какой момент её можно развернуть, и есть подтверждение, что она читается. Без этого команда узнаёт о проблеме в момент аварии: архив на диске лежит, а развернуть его нечем или не из чего собрать цепочку. Именно на это настроен pgBackRest — не на факт создания копий, а на предсказуемое восстановление.
Точка восстановления и расписание
Полная копия раз в сутки, дифференциальные — каждые несколько часов, журналы транзакций уходят в хранилище непрерывно. Это задаёт точку восстановления с точностью до минуты: откат возможен не только на ночной срез, но и на момент перед ошибочным изменением данных. Политика хранения держит нужное число поколений, поэтому окно отката исчисляется неделями, а не последним архивом.
Проверка целостности и тестовые восстановления
Копия считается годной только после проверки контрольных сумм и разбора всей цепочки журналов — инструмент делает это по расписанию и указывает первый повреждённый сегмент. Раз в месяц мы разворачиваем копию на отдельном стенде и замеряем время восстановления базы: на выходе не оценка «примерно», а факт — сколько минут занимает подъём.
Так уходит класс отказов «копия есть, восстановить нельзя»: каждая копия проверена, цепочка собрана, время восстановления известно заранее. Регулярность копирования и проверок выведена в мониторинг — пропущенное окно видно сразу, а не в момент, когда копия понадобилась.
Сравнение режимов резервного копирования и хранения
Режимы не конкурируют, а складываются в слои: полное копирование задаёт базу для восстановления, инкрементальное и дифференциальное сокращают объём и окно, непрерывная архивация журналов определяет точку, на которую можно вернуться. Ошибка — выбрать один вариант и ждать от него всего сразу.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полное копирование | Первичная опора, база для цепочек, редко меняющиеся базы | Долго читает диск, растёт объём и трафик на репозиторий |
| Инкрементальное копирование | Большие базы с интенсивной записью, нужен частый бэкап | Восстановление тянет всю цепочку; повреждение сегмента ломает ветку |
| Дифференциальное копирование | Компромисс: цепочка короче, чем у инкрементов | Копия растёт между полными — при частом запуске выигрыш пропадает |
| Непрерывная архивация журналов | Нужна точка восстановления в пределах минут | Не заменяет базовую копию: журналы хранят вместе с ней |
| Внешняя реплика | Быстрое переключение, разгрузка основного узла | Логическую ошибку не ловит — удаление уедет на реплику |
Локальный и внешний репозиторий
Локальный репозиторий быстрее: копия ложится на соседний том без сети, окно бэкапа короче. Но он умирает вместе с хостом — при отказе сервера или шифровании дисков исчезает и копия. Внешний репозиторий на отдельном узле переживает отказ основного, и pgBackRest пишет в два репозитория параллельно: локальный остаётся для быстрого отката.
Хранение и ротация
Правило хранения фиксирует, сколько полных копий и цепочек журналов лежит на диске, остальное чистится по расписанию — объём реестра перестаёт расти, а откат на нужную глубину сохраняется. Целостность подтверждаем восстановлением на тестовый узел, а не статусом «задача завершилась успешно».
Настройка pgBackRest: этапы внедрения и передачи
Работу ведём этапами: каждый следующий шаг опирается на подтверждённый результат предыдущего, поэтому ошибка видна до того, как изменения попадут в рабочую базу. Ниже — последовательность, по которой проходит внедрение.
Подготовка инфраструктуры
- Аудит резервного копирования. Смотрим, что копируется сейчас, куда пишутся дампы, сколько хранятся, какие объёмы и когда открыто окно обслуживания.
- Схема размещения репозиториев. Решаем, где живёт репозиторий — локальный диск, отдельный сервер или объектное хранилище. Отдельный репозиторий под каждую базу упрощает восстановление одной базы, не задевая остальные.
- Настройка копирования. Полный бэкап по расписанию, инкрементальные между ними, непрерывный архив WAL. Политика хранения держит копии за нужный период, остальное чистится — репозиторий не растёт бесконечно.
- Расписание и контроль. Копирование ставим в окно минимальной нагрузки, проверяем завершение и настраиваем оповещения: сигнал приходит при ошибке или пропуске, а не при следующем разборе отказа.
Проверка на тестовом контуре
- Тестовое восстановление. Разворачиваем копию на отдельном контуре — до нужной точки во времени, с замером времени восстановления. Бэкап считается готовым только после успешного восстановления.
- Регламент и передача в эксплуатацию. Передаём документацию: где лежат репозитории, как запустить восстановление, как проверить целостность, кому идёт оповещение. Фиксируем, кто что делает при отказе — на своей стороне или на стороне заказчика.
Артефакты внедрения: конфигурации, регламенты, документация
На выходе в инфраструктуре остаётся не «настроенный сервер», а комплект артефактов, по которым копирование дальше сопровождает ваша команда без нас. Каждый пункт проверяем на приёмке: конфигурацию можно развернуть на новом узле, регламент — прочитать и выполнить в ночную смену.
- Конфигурация pgBackRest: параметры репозитория, расписание, шифрование и сжатие, привязка к кластеру и правила исключений.
- Политика хранения копий: сколько полных и промежуточных наборов держим, какая глубина по времени, как работает автоматическая очистка.
- Регламент восстановления: пошаговый сценарий полного и точечного восстановления на отдельный узел, с обязательной проверкой на тестовом контуре.
- Разграничение доступов: роли на запись и чтение репозитория, отдельный служебный пользователь, ограничение доступа к ключам шифрования и журналам.
- Инструкция для дежурной смены: чек-лист утренней проверки, разбор типовых оповещений, порядок эскалации.
- Схема размещения: где лежат копии, что переживает отказ основной площадки, как устроен архив.
- Журнал учений: даты и результаты тестовых восстановлений, замеренное время до работоспособной базы.
Состав документации
Отдельно передаём описание архитектуры копирования, схему потоков данных, реестр изменений конфигурации и матрицу ответственных. Документация хранится рядом с кодом инфраструктуры, а не в переписке, — при смене инженера контекст не теряется.
Мониторинг и оповещения
Метрики копирования уходят в общую систему мониторинга: длительность, объём, статус последнего набора, отставание от расписания. Алерты разделены по критичности — отсутствие данных в ночное время отдельно от реального сбоя, чтобы дежурный не привык игнорировать уведомления.
Кейс: восстановление базы за минуты вместо часов
До перехода на потоковое архивирование восстановление базы после сбоя основного узла занимало от четырёх до шести часов: поднимали последний ночной дамп, вручную докатывали журналы, и каждая третья попытка заканчивалась расхождением данных. Копии физически существовали, но их никто не разворачивал до аварии — проверка шла уже в момент инцидента, когда каждая минута простоя складывалась в остановленные заказы.
Схему перестроили вокруг непрерывного архивирования и полных копий с наращиванием в pgBackRest: ежедневная полная копия, инкрементальные между ними и постоянная выгрузка журналов. Раз в сутки копия автоматически разворачивается на тестовом контуре и сверяется по контрольным суммам — пригодность восстановления подтверждается заранее, а не по факту отказа.
Что изменилось в повседневной эксплуатации
Время восстановления на тестовом контуре сократилось с четырёх-шести часов до восьми-двенадцати минут, доля успешных восстановлений выросла с 60 до 100 процентов: за всё время не прошла одна попытка, и причина была в повреждённом диске, а не в копии. Ушёл целый класс отказов — «резервная копия есть, но нечитаема»: битые и устаревшие наборы отсекаются автоматической проверкой и не доживают до аварии. Откат базы на предыдущее состояние стал рутинной операцией на несколько минут, поэтому обновления и миграции схемы перестали планировать под выходные.
Чем отличается горячий стенд от проверяемой копии?
Реплика и копия решают разные задачи, и путать их дорого. Реплика — это непрерывный поток изменений: она повторяет состояние основной базы почти без задержки и держит сервис доступным, если основной узел выпал. Копия — снимок на конкретный момент, который лежит отдельно от кластера и не зависит от того, что происходит с данными прямо сейчас.
Горячий резерв выручает при отказе железа: переключение занимает минуты, приложение продолжает работать на чтение и запись. Но он честно повторяет всё, что ему передали, — массовое удаление или ошибочная правка уезжает на стенд за секунды. Отката во времени у реплики нет, поэтому защитой от человеческой ошибки она не является.
Копия для проверок нужна именно для этого: её разворачивают в отдельный контур и на ней отрабатывают сценарии. Восстановление на точку до сбоя, сверка целостности, проверка, что приложение стартует и данные сходятся, — всё это делается на изолированной площадке, не затрагивая рабочий контур. Так регулярно подтверждается, что резерв действительно рабочий, а не просто существует.
pgBackRest в этой схеме закрывает полный и накопительный наборы копий: вернуться можно и на ночной снимок, и на нужный момент между ними, без пересборки кластера с нуля.
Выбор механизма восстановления зависит от класса сбоя: потеря узла — сценарий переключения на горячий резерв, испорченные данные — восстановление из копии. Поэтому в проекте обычно держат оба механизма, и у каждого свой порядок проверки.
Проверки восстановления, хранение копий и доступы
Проверяемость копий важнее их наличия. Мы не считаем резервное копирование работающим, пока не выполнен пробный разворот на отдельном стенде: разворачиваем полную копию, накатываем журнальные сегменты до точки перед сбоем, сверяем контрольные суммы и целостность индексов. Прогон идёт по расписанию, а результат попадает в отчёт — видно, какая копия проверена и на какую метку времени из неё поднимается кластер.
Чем доказывается, что база действительно восстановится?
Автоматическим прогоном восстановления на изолированном стенде. Если разворот не проходит, приходит оповещение с этапом, на котором он остановился, — а не отчёт «копирование выполнено успешно». Проверяется и целостность индексов, а не только факт запуска кластера.
Что с хранением, ротацией и сроками копий?
Копии уходят в отдельное хранилище в другом домене отказа, локальный диск под архив не переполняется: pgBackRest пишет потоково. Политика ротации задаётся явно — суточные копии держим месяц, недельные квартал, месячные год. Старые версии удаляются по расписанию, поэтому объём архива перестаёт расти линейно.
Кто имеет доступ к копиям и защищены ли они?
Доступ к архиву не совпадает с доступом к продуктивной базе: запись ведёт отдельная учётная запись, чтение и разворот — отдельная роль, ключи хранятся вне репозитория. Копии шифруются на стороне источника, поэтому вынесенный архив без ключа бесполезен. Об отказе хранилища или об истечении сроков узнаём из оповещений, а не из разбора после сбоя.
Обсудим задачу: что нужно от инфраструктуры на старте
Обсуждение задачи копирования начинается не с выбора параметров, а с инвентаризации того, что у вас уже развёрнуто. Нам нужны входные данные по инфраструктуре, чтобы вернуться не с общими словами, а с оценкой объёма работ и планом внедрения под ваш контур. Ниже — то, что стоит уточнить на первом разговоре.
- Схема размещения: сколько инстансов, есть ли реплики и управляемые кластеры, какие базы критичны для восстановления, а какие можно поднимать по остаточному принципу.
- Объёмы и профиль изменений: текущий размер баз, суточный прирост, доля «горячих» таблиц — от этого зависит тип резервных копий и частота их снятия.
- К чему стремимся по восстановлению: сколько данных допустимо потерять и за какое время система обязана вернуться в строй.
- Место хранения копий: локальный диск, сетевое хранилище, объектное хранилище, отдельная площадка — и есть ли требование держать копии за пределами основного контура.
- Доступы и роли: как выдаются учётные данные под служебные задачи, кто владелец бакета или каталога, как устроена ротация ключей.
- Ограничения окружения: окна обслуживания, правила сетевых фильтров между сегментами, требования к шифрованию при передаче и на диске.
- Что уже работает: старые дампы, скрипты по расписанию, ручные выгрузки — их придётся либо переносить, либо аккуратно выводить из эксплуатации.
Собрав это, мы фиксируем объём работ, порядок настройки и проверок и порядок передачи документации: конфигурации, описание политик хранения, инструкцию по восстановлению с проверенным сценарием отката на тестовом контуре. Опишите задачу и текущее состояние — вернёмся с оценкой и планом.
