Налаштування 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) тримається на безперервному ланцюжку журналів транзакцій: базовий зліпок плюс усі сегменти після нього.

Втрачено або вивантажено з помилкою один сегмент — відновлення зупиняється на останньому безперервному місці, а точка всередині розриву стає недосяжною. Тому повноту архіву контролюють постійно, а не з’ясовують у момент аварії.

Глибину відкату задає термін зберігання архівів: видалили сегменти за минулий місяць — точка місячної давності вже не піднімається. Нижче — технічні сумніви, які найчастіше обговорюємо перед стартом.

Як переконатися, що копія придатна до відновлення?

Придатність перевіряється не читанням журналу, а регулярним тестовим відновленням на окремому стенді: звірили контрольні суми сегментів, підняли копію, звірили цілісність даних. Термін зберігання при цьому беремо із запасом щодо найглибшого сценарію відкату.

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

Розбір іде в ізольованому контурі: робочий сервер не зупиняємо, навантаження користувачів не страждає. Якщо потрібна окрема таблиця, розгортаємо копію поряд і переносимо з неї потрібні рядки — це безпечніше повного відкату бази.

Обговоримо вашу задачу відновлення даних

Щоб оцінка була не «на око», а за фактом, на першому кроці нам потрібен мінімальний зріз по вашому контуру: де зараз лежать базові копії, як влаштована архівація журналів попереднього запису і наскільки регулярно хтось пробував відновлення.

Зі свого боку повернемо оцінку робіт, план упровадження і терміни — з розбивкою за етапами, щоб рішення можна було ухвалювати частинами.

Що потрібно від вас:

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

Що повернемо на першому кроці:

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

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