Бэкап и восстановление на точку (PITR)

Сместить вопрос с бэкапа на восстановление - не игра слов. Это меняет выбор инструмента. Спроси: на какой момент нужно уметь вернуться и за сколько? Ответы бывают разные:

• «вернуть вчерашнюю базу целиком» - хватит логического дампа;
• «вернуть состояние за минуту до аварии» - нужен PITR;
• «потерять не больше N секунд при падении» - это уже про синхронную репликацию, не про бэкап.

Каждый инструмент отвечает на свой класс вопросов. Дальше разберём два главных: логический дамп и PITR.

pg_dump обходит базу в одной транзакции и выгружает её содержимое (схему, данные или то и другое) как SQL или в своём custom-формате. Благодаря снимку MVCC дамп получается согласованным на один момент - начало дампа, ни секундой позже.

Свойства, которые определяют его применимость:

• снимок строго на момент старта, «докрутить до позже» нельзя;
• переносим между мажорными версиями и архитектурами - это способ мигрировать на новую версию;
• восстанавливается медленно на больших базах: это перезаливка данных и перестройка всех индексов с нуля.

Логический дамп хорош для «вернуть базу на вчера» и для миграций. Для «вернуть на 14:59, за минуту до рокового DROP» он бесполезен - нужного момента в нём просто нет.

Point-in-time recovery собирается из двух частей, и обе нам уже знакомы по механизму журнала:

1. Базовая копия - физический слепок кластера на некоторый момент, снятый pg_basebackup с работающего сервера.
2. Непрерывный архив WAL - сервер с archive_mode = on отдаёт каждый заполненный сегмент журнала командой archive_command в надёжное хранилище.

база на T0  ──┐

               ├──▶ восстановление: разворачиваем копию,

WAL: T0 ─────▶ T1 ─────▶ T2 ─────▶ now

                          проигрываем WAL до recovery_target_time

Имея копию на T0 и весь WAL после неё, можно развернуть копию и проиграть журнал ровно до нужной точки. Это тот же replay, что в crash recovery, - только конец задаём не «до последней записи», а явной целью: по времени (recovery_target_time), по LSN или по именованной точке восстановления.

Классика, ради которой PITR и существует. В 15:00 кто-то выполнил DROP TABLE orders на проде. Есть ночная базовая копия и непрерывный архив WAL. Восстановление:

1. развернуть ночную копию в отдельный каталог;
2. задать цель recovery_target_time = момент перед DROP (скажем, 14:59:59);
3. дать restore_command, чтобы сервер подавал себе архивные сегменты WAL;
4. поднять сервер - он проиграет журнал от ночной копии до 14:59:59 и остановится.

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

Самая обидная засада в PITR. archive_mode - параметр уровня сервера, он применяется только при рестарте. Включить его на лету нельзя - в отличие от archive_command, который перечитывается по reload.

Из этого следует жёсткое правило: архив включают заранее, в спокойное время, а не в тот момент, когда копия уже понадобилась. Если archive_mode был off, то WAL за прошедшее время уже не архивировался - и восстанавливать PITR не из чего, как бы быстро ты сейчас ни включил архив.

-- архив включён и применился, или ещё ждёт рестарта?

SELECT name, setting, pending_restart

FROM pg_settings WHERE name IN ('archive_mode', 'archive_command');

pending_restart = true на archive_mode означает «я поменял настройку, но она вступит в силу только после рестарта» - до него архив не работает.

Полезная ментальная модель: то, что снимает pg_basebackup, - не «архив для распаковки», а готовый кластер. Это побайтовая копия PGDATA, которую можно просто запустить вторым сервером, и она поднимется с теми же данными на момент копии.

Отсюда видно родство с физической репликацией из прошлой части: standby начинается ровно с такой базовой копии, к которой потом доливается поток WAL. PITR - это та же копия плюс архив, но с явной точкой остановки вместо бесконечного догоняющего потока.

Поэтому проверка бэкапа проста и обязательна: разверни базовую копию отдельным сервером и убедись, что он стартует и данные на месте. Бэкап, который ни разу так не проверяли, в день аварии может оказаться нерабочим - и это выяснится в худший момент. Какие именно файлы копируются и как устроен replay - это форки и журнал из предыдущих частей; справка - backup-pitr.