Налаштування резервного копіювання 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 додає до нього інкрементальні копії та перевірку цілісності перед розгортанням — відновлення перестає залежати від того, чи вцілів вузол.

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

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

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

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

Архів шифрується і хто має до нього доступ?

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

Скільки живуть копії і що при обриві зв’язку зі сховищем?

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

Обговоримо завдання резервного копіювання й повернемося з планом

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

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

Що входить у роботу:

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

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