Настройка PITR PostgreSQL: восстановление на момент времени

PostgreSQL PITR: где теряются данные между копиями

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

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

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

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

Непрерывное архивирование журнала: что меняется на практике

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

Точка восстановления вместо целых суток

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

Какой класс отказов закрывается

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

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

Полная копия, журнал транзакций или репликация: сравнение

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

Когда достаточно полной копии

Если потеря нескольких часов работы допустима, база укладывается в разумное окно копирования, а требования «откатиться на минуту до сбоя» нет — хватает регулярной полной копии и периодической проверки восстановления на отдельном контуре. Контур прост в обслуживании, но точка восстановления жёстко привязана к расписанию.

Когда нужна комбинированная схема

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

Порядок внедрения восстановления на момент времени

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

1. Аудит копий и журнала — инвентаризация базовых копий, непрерывности журнального архива, глубины хранения и найденных разрывов.
2. Схема хранения архивов — базовые копии и журнальные сегменты разводятся по срокам жизни, площадкам и правилам выгрузки за пределы контура.
3. Настройка архивации — включаем непрерывную отгрузку сегментов, фиксируем параметры конфигурации, убираем всё, что рвёт поток.
4. Опорная копия и контроль целостности — снимаем базовую копию и проверяем её читаемость до того, как она понадобится.
5. Целевая точка — договариваемся, до какого момента восстанавливаемся: последняя транзакция, начало сбоя или метка времени в журнале.
6. Отработка сценариев — тренируем восстановление на промежуточный момент, а не только на последний доступный.

Проверка на отдельном контуре

Восстановление поднимаем на изолированном стенде, не на боевом узле. Сверяем контрольные суммы, объёмы по ключевым таблицам и фиксируем время от команды до готовности принимать нагрузку.

Передача эксплуатации и регламент

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

Что остаётся в контуре: конфигурации, схемы, регламенты

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

Настройки архивации и сроки хранения

• конфигурация архивации: изменённые параметры (archive_mode, archive_command, wal_level) с пояснением, зачем каждый нужен и что сломается при откате к значению по умолчанию;
• расписание полного и инкрементального бэкапа, окно запуска, лог успешности и оповещение при пропуске;
• срок хранения копий: сколько живёт журнал изменений и полная копия, что чистится автоматически и какое правило оставляет запас для отката;
• проверка: тестовое восстановление на отдельном инстансе по расписанию с записью результата.

Документация и памятка дежурному

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

Кейс: восстановление после массового удаления данных

Логический сбой — единственный класс аварий, где реплика не спасает: DELETE без условия мгновенно уезжает в поток репликации, и резервный узел становится такой же пустой копией кластера PostgreSQL, как основной. В этом кейсе таблица с заказами потеряла рабочую выборку за секунды, а заметили это по жалобам операторов только через несколько часов. Ниже — как было устроено восстановление до инцидента и что поменяли.

Как было до

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

Что изменилось после

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

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

Чем PostgreSQL PITR отличается от репликации и снимков диска

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

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

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

Разница — в задаче. Репликация отвечает за доступность и разгрузку чтения, снимок — за быстрый возврат после потери тома. Восстановление на момент времени закрывает ошибки: неудачное обновление, массовое удаление, сбой пакетной обработки.

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

Ограничения и частые сбои восстановления на момент времени

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

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

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

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

Восстановление затронет рабочий контур? Можно поднять одну таблицу?

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

Обсудим вашу задачу восстановления данных

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

Что нужно от вас:

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

Что вернём на первом шаге:

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

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