Настройка PostgreSQL бэкапирования через WAL-G

Резервное копирование WAL-G PostgreSQL: что ломается

Ночной полный дамп завершается с кодом 0, отчёты зелёные, а после повреждения данных кластер поднимается из копии суточной давности. Операции за прошедшие сутки — заказы, платежи, правки справочников — приходится собирать вручную из внешних систем. Ошибка в дампе вскрывается только в момент аварии, когда времени на разбор уже нет.

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

<cite>WAL-G</cite> закрывает этот разрыв: базовая копия снимается редко, а архив журнала транзакций пополняется непрерывно. Точка восстановления смещается с суток на конкретную секунду — можно откатиться к состоянию перед ошибочным обновлением. Настройка WAL-G при этом включает политику хранения, шифрование и выгрузку в объектное хранилище.

Отдельная часть работы — регулярная проверка: архив разворачивается на отдельном стенде, сверяется целостность, замеряется время восстановления. Без этого архив есть, а поднять из него кластер не получается.

Ниже разбираем, где такая схема ломается чаще всего и как выглядит резервное копирование PostgreSQL, которое переживает аварию.

Что даёт непрерывный архив журнала транзакций

Ежедневный полный дамп отвечает на вопрос «как восстановиться к утру», но не закрывает последние часы работы. Сбой или неудачная миграция в середине дня откатывают базу к ночной копии, и всё, что было после неё, приходится собирать вручную по логам приложений. Непрерывное резервное копирование на WAL-G убирает эту дыру: сегменты журнала транзакций уезжают в объектное хранилище по мере заполнения, а не по расписанию.

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

Время восстановления базы становится предсказуемым: базовые копии снимаются реже и в фоне, без ночного окна, когда сервер занят выгрузкой. Защита данных перестаёт зависеть от одного расписания — архив проверяется пробной развёрткой на отдельном стенде, поэтому битый сегмент находится до аварии, а не во время неё. В итоге уходит целый класс отказов «потеря последних часов работы», а возврат к контрольной точке превращается в штатную операцию.

Режимы архивации WAL-G PostgreSQL: сравнение подходов

WAL-G выполняет два независимых действия: непрерывно выгружает сегменты журнала предзаписи в объектное хранилище и периодически снимает полный снимок базы. Восстановление всегда опирается на снимок, а журнал лишь доигрывает изменения до нужной точки — поэтому выбор режима архивации это в первую очередь вопрос допустимого окна потери данных и предсказуемости времени возврата в строй.

На практике сравнивают четыре схемы. Разница проявляется не в момент настройки, а в момент аварии, когда нужно поднять базу за отведённое окно.

Гибридная схема резервного копирования закрывает большинство задач: снимок по расписанию даёт надёжную основу, непрерывный архив — точку внутри интервала, а реплика для чтения снимает часть нагрузки и сокращает простой при отказе.

Отдельно подчеркнём: реплика не является бэкапом. Ошибочное удаление или порча данных мгновенно повторяются на ней, поэтому независимая копия в хранилище с версионированием и отдельными правами остаётся обязательной. Какой режим архивации нужен вам — зависит от требуемой точки восстановления; разберём это при обсуждении задачи.

Внедрение: от аудита кластера до передачи регламентов

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

1. Аудит кластера. Версия, топология реплик, темп генерации журналов, существующие скрипты и их расписание. На выходе — перечень разрывов, из-за которых непрерывной архивации сейчас нет.

2. Схема хранения. Объектное хранилище, раскладка базовых копий и журналов, удержание и правила удаления — реестр не растёт бесконтрольно, а откат на нужную точку остаётся возможным.

3. Настройка архивации. Параметры журналирования, доступы, шифрование, ротация. Доставку журналов и базовых копий в хранилище закрывает WAL-G, он же проверяет целостность архивов.

4. Проверка на отдельном стенде. Разворачиваем копию из архива, замеряем время полного отката и отката на точку во времени, сверяем контрольные суммы.

5. Автоматизация контроля. Ежедневное тестовое восстановление, оповещения о разрыве цепочки журналов и устаревшей копии, отчёт о свежести архива.

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

7. Передача регламентов. Схема, конфигурации, пошаговые инструкции, чек-листы, матрица ответственных — дежурный восстанавливает кластер без звонка разработчику.

Комплект конфигураций, схем и регламентов на выходе

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

• Файлы настроек архивации журналов и базовых копий — с комментариями к каждому параметру: глубина хранения, расписание, ротация, обработка сбоев записи в репозиторий.
• Схема инфраструктуры: где стоят базы, куда пишутся копии, какие узлы и зоны отказа задействованы, где проходит шифрование и как хранятся ключи.
• Политики доступа: роли на чтение и запись репозитория, кто вправе запускать восстановление, разделение обязанностей и порядок выдачи и отзыва прав.
• Регламент резервного копирования: типы копий, периодичность, срок хранения, точки восстановления на заданный момент времени и действия при нехватке места.
• Журнал проверок восстановления: дата, объём, время до работоспособности базы, результат сверки контрольных сумм и список найденных расхождений.
• Порядок действий при аварии: пошаговый сценарий с точками принятия решения, критериями переключения на копию и планом отката.
• Инструкция для дежурной смены и оповещения: какие метрики архивации отслеживаются, при каких порогах срабатывает сигнал и кому он адресован.

Комплект обновляется при каждом изменении конфигурации — иначе документация по резервному копированию расходится с реальностью за пару месяцев. Опишите текущее окружение, и мы вернёмся с оценкой и планом работ.

Кейс: восстановление после повреждения дискового массива

Ночью вышел из строя контроллер дискового массива, и база перешла в режим только для чтения. Последний логический дамп был снят почти за сутки до аварии, поэтому оценочно потерялось около 20 часов операций: заказы, статусы оплат, правки каталога. Сервис стоял девять часов, пока копия поднималась из дампа, а расхождения с внешними системами разбирали вручную ещё несколько дней.

Перешли на непрерывную выгрузку журналов предзаписи в объектное хранилище: суточный базовый снимок, поверх него — сегменты журнала каждые несколько минут, отдельные политики хранения и контроль целостности по контрольным суммам. WAL-G шифрует архив на стороне базы, продолжает цепочку после обрыва канала и позволяет восстановить состояние на произвольный момент времени, а не на момент снимка. Старые копии не копятся: правило жизненного цикла оставляет нужное число поколений и чистит остальное, поэтому архив не растёт бесконтрольно.

Точка восстановления сократилась с суток до минут, а подъём базы — с девяти часов до 25 минут на отдельном контуре. Раз в квартал проводим учения: поднимаем копию из архива, сверяем число записей и ключевые агрегаты, замеряем время до готовности сервиса. Битые сегменты и расхождения ловим на учениях, а не в момент аварии — целостность данных подтверждается проверками, а не предположениями.

Чем отличается архив журнала от логической репликации?

Реплику часто путают с резервной копией, хотя горизонт у них разный. Реплика постоянно применяет изменения с основного узла и держит состояние на текущий момент: через несколько секунд после ошибочного изменения без условия на ней будет тот же испорченный набор данных. Истории она не хранит — откатить её назад нельзя, потому что прошлого в ней просто нет.

Архив журнала устроен наоборот: это непрерывная цепочка изменений, накопленная во времени. Восстановление на точку во времени разворачивает базовую копию и проигрывает изменения до нужной метки — состояние за минуту до сбоя, до неудачной правки схемы или до порчи данных выгрузкой. Глубину отката задаёт срок хранения архива, а не момент последней синхронизации, поэтому доступны любые точки прошлого внутри этого окна.

Логическая репликация решает третью задачу — передаёт изменения разобранными операциями и позволяет держать реплику для чтения. Отчёты и тяжёлые выборки уходят с основного узла, не мешая записи, а переключение при отказе занимает секунды. Но покрывает такая реплика только текущее состояние и логическую ошибку разносит по всем узлам с той же скоростью.

Поэтому механизмы не заменяют, а дополняют друг друга: реплика закрывает доступность и нагрузку на чтение, архив — сохранность и откат на любую точку прошлого. Сбор журнала строят поверх объектного хранилища, а WAL-G добавляет к нему инкрементальные копии и проверку целостности перед разворотом — восстановление перестаёт зависеть от того, уцелел ли узел.

Технические сомнения: целостность, совместимость, проверка

Перед переключением на непрерывное архивирование инженеры задают один и тот же набор вопросов: что с совместимостью, как проверить копию, кто видит архив и как долго он живёт. Ниже — прямые ответы: они же становятся пунктами приёмки.

Как убедиться, что копия действительно восстановится?

Непроверенная копия — надежда, а не гарантия. Разворачиваем архив на отдельном стенде по расписанию, сверяем целостность данных и восстанавливаем состояние на произвольную точку во времени. Итог последней сверки фиксируем в журнале — видно, когда копия реально поднималась.

Архив шифруется и кто имеет к нему доступ?

Шифрование включается до отправки в хранилище, ключ живёт вне облачного бакета: без него содержимое архива не читается даже при доступе к объектам. Ключи ротируем и храним отдельно от самих копий.