PITR без сюрпризов: проверяем восстановление PostgreSQL

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

Point-in-Time Recovery (PITR) решает именно эту задачу: base backup плюс непрерывный архив WAL позволяют воспроизвести состояние базы на любую секунду между двумя бэкапами, а не только на момент снапшота. Проблема в том, что PITR — это не «включил и забыл»: сломанный archive_command тихо копит недоархивированные WAL, неправильная retention-политика удаляет как раз тот сегмент, который нужен для восстановления, а timeline и recovery_target путают даже опытных инженеров в момент инцидента, когда цена ошибки максимальна. В этой статье разберём механику WAL-архива, timeline, retention и восстановление в новый кластер, — а в конце соберём автоматизированную проверку точки восстановления и измерение RPO, чтобы доказывать способность восстановиться, а не предполагать её.

Как устроен PITR в PostgreSQL и почему это не просто «бэкап + вчера»

PostgreSQL непрерывно ведёт write-ahead log (WAL) — журнал всех изменений в файлах данных, изначально нужный для восстановления после сбоя. PITR использует этот же журнал иначе: если сохранять WAL-сегменты по мере их заполнения и держать один базовый бэкап, можно «доиграть» журнал до любой точки между бэкапом и текущим моментом, получив консистентное состояние базы на нужную секунду.

1. WAL, base backup и как из двух частей получается точка восстановления

Восстановление через PITR всегда собирается из двух независимых частей: базового бэкапа файлов кластера (base backup) и непрерывной последовательности WAL-сегментов, которая начинается не позже старта этого бэкапа. По отдельности эти компоненты не имеют ценности: копия данных без WAL-файлов восстановит кластер только на фиксированный момент времени, а WAL-сегменты невозможно применить без исходных файлов базы данных.

• Base backup — простейший способ снять его: pg_basebackup, который копирует файлы кластера и создаёт backup_label с именем стартового WAL-сегмента. Он не обязан быть идеально консистентным сам по себе — реплей WAL исправит внутренние несоответствия так же, как это происходит при восстановлении после сбоя.
• WAL-архив — непрерывный архив, который включается через wal_level=replica (или выше), archive_mode=on и archive_command (или archive_library в новых версиях), выполняемую при заполнении каждого 16-мегабайтного сегмента.
• Точка восстановления — любой момент между временем окончания base backup и последним доступным WAL-сегментом; восстановиться раньше, чем закончился base backup, невозможно — для этого нужен более старый бэкап.

1.1. archive_command: типичные ошибки

archive_command — это просто shell-команда, которую PostgreSQL считает успешной по нулевому коду возврата, и здесь чаще всего проседает вся цепочка PITR.

• Команда должна возвращать ненулевой код при неудаче — иначе PostgreSQL решит, что сегмент заархивирован, и переиспользует его, оставив дыру в цепочке WAL.
• Команда не должна перезаписывать уже существующий в архиве файл с другим содержимым — это защита от ситуации, когда в один архив случайно пишут два разных кластера.
• Для низкой WAL-нагрузки стоит задать archive_timeout (обычно порядка минуты) — иначе последний сегмент может не закрываться часами, и «хвост» изменений не попадёт в архив вовремя.
• pg_stat_archiver — источник правды по факту, а не по ощущениям: в нём видно время последнего успешного архивирования и счётчик неудач.
• Если каталог с архивом переполнится или станет недоступен, pg_wal/ начнёт расти, а при исчерпании места на диске PostgreSQL уходит в PANIC-остановку.

2. Timeline: почему «восстановили не туда» не катастрофа

Восстановление базы данных на момент времени в прошлом (PITR) создаёт развилку: PostgreSQL присваивает новую timeline каждой такой развилке, чтобы WAL, сгенерированный после восстановления, не перезаписал сегменты из истории, к которой ещё можно захотеть вернуться. Timeline ID зашит в первых восьми символах имени WAL-файла, а при каждом переключении в архив попадает небольшой .history-файл с описанием, откуда эта ветка была создана.

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

3. Retention: сколько хранить WAL и бэкапов

Retention в PITR — это компромисс между стоимостью хранения и глубиной восстановления, но у него есть жёсткое ограничение снизу: нельзя хранить WAL меньше, чем интервал между базовыми бэкапами, иначе цепочка восстановления разрывается физически, а не по регламенту. Чем реже снимается base backup, тем больше WAL нужно хранить и тем дольше длится реплей при восстановлении — это не бесплатная экономия места.

Начиная с PostgreSQL 17, pg_basebackup поддерживает инкрементальные бэкапы (--incremental) поверх WAL summary, а pg_combinebackup собирает из цепочки полного и инкрементальных бэкапов синтетический полный бэкап при восстановлении — это снижает объём хранения по сравнению с ежедневными полными бэкапами при сопоставимой скорости восстановления.

4. recovery_target: как указать секунду, транзакцию или LSN

Момент восстановления задаётся одним из нескольких взаимоисключающих параметров: recovery_target_time — конкретная временная метка, recovery_target_lsn — позиция в WAL, recovery_target_xid — конкретная транзакция, recovery_target_name — именованная точка, заранее созданная функцией pg_create_restore_point(), или recovery_target=immediate — восстановиться ровно до момента консистентности base backup. recovery_target_inclusive определяет, включается ли сама целевая транзакция или момент в восстановление.

5. Восстановление в новый кластер: пошагово

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

• Развернуть base backup в новый, пустой каталог данных — не поверх боевого кластера, и убедиться, что владельцем файлов и каталогов является системный пользователь postgres и у него есть необходимые права доступа.
• Очистить pg_wal/ в новом каталоге от файлов, скопированных вместе с base backup, — они устарели и являются частью самого бэкапа, а не архива.
• Указать restore_command, нужный recovery_target_* и recovery_target_action в конфигурации нового кластера.
• Создать файл recovery.signal в каталоге данных для восстановления standalone-сервера (standby.signal — если поднимается standby).
• Запустить новый кластер на отдельном порту/хосте — он войдёт в режим восстановления и начнёт вычитывать WAL из архива.
• Проверить данные: убедиться, что нужные строки и таблицы есть, а более поздние нежелательные изменения — отсутствуют.
• Если recovery_target_action=pause, разрешить реплей командой pg_wal_replay_resume() после проверки, либо перезапустить с другим recovery_target, если точка выбрана неверно.
• Только после подтверждения переключить приложение на новый кластер или выгрузить нужные данные обратно в прод.

Как PITR закрывает типовые риски

Сравнение: pg_dump, файловый бэкап и PITR через WAL-архив

Типовой план внедрения PITR

Частые вопросы команд про PITR

Ключевые термины PITR

Чек-лист готовности PITR

Практические сценарии использования PITR

Рассмотрим несколько задач, с которыми регулярно сталкиваются команды, эксплуатирующие PostgreSQL в проде, и разберём, как PITR решает их с точки зрения точности восстановления, изоляции риска и доказуемости результата.

Кейс 1. Восстановление после атаки шифровальщика

Проблема

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

Решение на базе PgBouncer

PITR позволяет восстановиться на точку до предполагаемого момента компрометации, а не просто на «последний бэкап». Восстановление выполняется в изолированной от прод-сети среде — как минимум до тех пор, пока не подтверждено, что источник компрометации закрыт.

Типовая архитектура

• Восстановленный кластер поднимается в изолированном сегменте сети без доступа к боевым интеграциям и очередям.
• recovery_target_lsn или recovery_target_time сверяется с данными SIEM/логов доступа для выбора точки до компрометации, а не просто «на всякий случай пораньше».
• Прогон нескольких точек восстановления на разных timeline, если момент компрометации не установлен точно.
• Ротация всех учётных данных и ключей перед тем, как открывать восстановленный кластер на запись. Что теряет команда, если оставить статус-кво
• Восстановление из «последнего бэкапа» рискует вернуть в прод те же уязвимости или уже изменённые злоумышленником данные.
• Нет способа документально подтвердить точный момент, на который восстановлена система.
• Расследование инцидента усложняется, если WAL-архив короче, чем время между проникновением и обнаружением.

Бизнес-цель

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

Тезисы для питча

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

Кейс 2. Регулярный автоматический restore-drill

Проблема

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

Типовая архитектура

• Отдельная изолированная инфраструктура (эфемерные контейнеры/VM) для каждого прогона restore-drill.
• Контрольный набор данных и чек-сумма таблиц, которые проверяются после восстановления на соответствие ожидаемому состоянию.
• Метрики прогона (время восстановления, измеренный RPO) отправляются в тот же мониторинг, что и остальная инфраструктура.
• Алерт при неудачном восстановлении или превышении целевого RPO/RTO — до того, как это понадобится в реальном инциденте.

Что теряет команда, если оставить статус-кво

• Первая реальная проверка восстановления происходит во время настоящего инцидента — худший момент для обнаружения сломанного archive_command.
• RPO и RTO существуют только на бумаге и не подтверждены измерением.
• Изменения инфраструктуры (обновление версии PostgreSQL, смена хранилища) могут незаметно сломать процесс восстановления.

Бизнес-цель

Превратить способность восстановиться из предположения в регулярно подтверждаемый и измеряемый факт.

Тезисы для питча

• Доказуемость: RPO и RTO подтверждены тестом, а не документацией.
• Раннее обнаружение: сломанное архивирование или retention находится по алерту, а не по факту неудачного восстановления при инциденте.
• Повторяемость: тот же процесс, что использовался бы в реальном инциденте, регулярно проверяется автоматически.

Кейс 3. Клонирование прод-базы на конкретный момент для стейджинга и аналитики

Проблема

Команде аналитики или QA нужен консистентный слепок прод-базы на определённый момент времени — например, состояние на начало квартала для отчётности или состояние прямо перед конкретным релизом для воспроизведения бага. Прямое клонирование прод-кластера нагружает боевую базу и не даёт зафиксировать конкретный исторический момент.

Типовая архитектура

• Восстановление в отдельный кластер с recovery_target_time на нужный исторический момент.
• Маскирование или анонимизация чувствительных данных перед выдачей доступа аналитикам или QA, если это требуется политикой безопасности.
• Тот же процесс, что используется для аварийного восстановления, — дополнительная регулярная проверка работоспособности PITR «бесплатно».

Что теряет команда, если оставить статус-кво

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

Бизнес-цель

Дать аналитике и QA воспроизводимые исторические слепки данных без нагрузки на прод и заодно регулярно проверять сам механизм PITR.

Тезисы для питча

• Точность: можно зафиксировать любой исторический момент внутри окна retention, а не только дату снапшота.
• Отсутствие нагрузки на прод: восстановление идёт из архива, а не через прямое копирование боевого кластера.
• Побочная выгода: каждое такое клонирование — дополнительная проверка того, что аварийный PITR действительно работает.

Тестовый стенд: автоматическая проверка точки восстановления и измерение RPO

Способность восстановиться доказывается только реальным восстановлением, а не наличием файлов в архиве. Ниже — минимальный стенд, который можно запускать по расписанию (cron/CI) и получать измеренный RPO, а не предполагаемый.

• Поднять PostgreSQL с включённым архивированием (wal_level=replica, archive_mode=on, archive_command, копирующий сегменты в локальную или S3-подобную директорию) в docker-compose или аналогичном стенде.
• Снять base backup через pg_basebackup сразу после старта архивирования.
• Сгенерировать фоновую нагрузку — pgbench -T или собственный скрипт с понятными контрольными данными, например таблица с меткой времени каждой вставки.
• Зафиксировать «инцидент»: создать именованную точку pg_create_restore_point('before_incident'), продолжить нагрузку ещё некоторое время, затем эмулировать сбой (например, DROP TABLE на контрольной таблице).
• Развернуть новый кластер из base backup, настроить restore_command и recovery_target_name='before_incident' (или recovery_target_time), создать recovery.signal и запустить восстановление.
• Проверить контрольные данные: последняя строка в восстановленном кластере должна соответствовать моменту непосредственно перед инцидентом, а не более поздним записям.
• Измерить фактический RPO: разница между временной меткой последней восстановленной записи и временем самого инцидента — это и есть измеренный RPO конкретного прогона, который можно сравнить с целевым SLA.
• Уничтожить временный кластер и записать результат прогона (успех/неудача, время восстановления, измеренный RPO) в общий мониторинг.

Как считать RPO по факту, а не по регламенту

Целевой RPO — это то, что заявлено в SLA («не более 5 минут потерь»). Фактический RPO конкретного инцидента или прогона restore-drill — это разница между временем инцидента и временной меткой последней транзакции, которая гарантированно попала в архив к этому моменту; её можно оценить по времени последнего успешного архивирования из pg_stat_archiver, ближайшему к моменту инцидента. Если фактический RPO стабильно выше целевого, проблема почти всегда в отставании archive_command под нагрузкой, а не в самой архитектуре PITR.

• Restore-drill — по расписанию, не реже, чем меняется инфраструктура или конфигурация бэкапов.
• Каждый прогон фиксирует измеренный RPO и время восстановления, а не только факт «успех/неудача».
• Алерт — не только на неудачное восстановление, но и на измеренный RPO, превышающий целевой SLA.
• Именованные точки восстановления перед рискованными операциями — дешёвая страховка, которая не требует знать точное время задним числом.

Заключение

Возможность восстановить PostgreSQL на нужную секунду не появляется автоматически вместе с включённым архивированием WAL — она складывается из работающего archive_command, retention, который не разрывает цепочку восстановления, понятной модели timeline и recovery_target, а главное — из процесса, который восстановление действительно проверяет.

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

При этом бэкап, который никогда не восстанавливали, — это предположение, а не гарантия. Автоматизированный restore-drill с измерением фактического RPO переводит вопрос «а мы точно восстановимся» из области веры в область регулярно подтверждаемого факта.

Именно поэтому PITR стоит проектировать вместе с процессом его проверки с самого начала — retention, recovery_target и runbook восстановления бесполезны, если единственный раз, когда их проверяют, — это реальный инцидент.

В Cloud Databases резервное копирование и PITR настраиваются через интерфейс. При сбое выберите нужную точку восстановления и разверните базу данных на новом инстансе — без ручной настройки процесса.

Процесс восстановления (скрины)