Налаштування pgBackRest: де ламається бекап PostgreSQL
pgBackRest налаштовується за пару годин, і копії починають з’являтися за розкладом. Але переповнення репозиторію ламає процес тихо: обсяг зростає швидше за політику зберігання, і коли місце закінчується, перестають прийматися і повні копії, і журнальні сегменти.
Збій резервного копіювання спливає не за тривогою, а за фактом відсутності свіжої копії — зазвичай під час аварії.
Окрема пастка — розрив в архівації журналів. Архівний процес може відставати або зупинитися після перезапуску сервера, тоді як повні копії продовжують створюватися за розкладом.
Формально копії є, але відновлення на потрібну точку неможливе: між останньою копією та інцидентом залишається діра, яку нічим закрити.
Ще одне джерело помилки відновлення з копії — розбіжність розкладів.
Копіювання, архівація журналів і очищення старих копій живуть у різних таймерах; коли вікно копіювання перекривається з вікном очищення, політика зберігання видаляє опорну копію, від якої залежать інкрементальні. Відновлення падає з повідомленням про відсутній сегмент саме тоді, коли копія потрібна найбільше.
Неперевірена копія — найдорожчий клас відмов: звіти про успішне завершення не доводять, що кластер підніметься з цих даних. Пошкоджений сегмент, невідповідність версій, нестача прав на каталог відновлення виявляються лише на реальному прогоні на окремому стенді.
Розбираємо, як це закривається: контроль місця та термінів зберігання в репозиторії, моніторинг архівації журналів, узгоджені вікна завдань і відновлення з перевіркою цілісності.
Відновлення до потрібної точки та перевірка цілісності копій
Резервна копія корисна рівно настільки, наскільки точно відомо, на який момент її можна розгорнути, і є підтвердження, що вона читається. Без цього команда дізнається про проблему в момент аварії: архів на диску лежить, а розгорнути його нічим або нема з чого зібрати ланцюжок. Саме на це налаштований pgBackRest — не на факт створення копій, а на передбачуване відновлення.
Точка відновлення та розклад
Повна копія раз на добу, диференціальні — кожні кілька годин, журнали транзакцій надходять у сховище безперервно. Це задає точку відновлення з точністю до хвилини: відкат можливий не лише на нічний зріз, а й на момент перед помилковою зміною даних.
Політика зберігання тримає потрібну кількість поколінь, тому вікно відкату обчислюється тижнями, а не останнім архівом.
Перевірка цілісності та тестові відновлення
Копія вважається придатною лише після перевірки контрольних сум і розбору всього ланцюжка журналів — інструмент робить це за розкладом і вказує перший пошкоджений сегмент.
Раз на місяць ми розгортаємо копію на окремому стенді та заміряємо час відновлення бази: на виході не оцінка «приблизно», а факт — скільки хвилин займає підняття.
Так зникає клас відмов «копія є, відновити не можна»: кожна копія перевірена, ланцюжок зібрано, час відновлення відомий заздалегідь. Регулярність копіювання та перевірок виведена в моніторинг — пропущене вікно видно одразу, а не в момент, коли копія знадобилася.
Порівняння режимів резервного копіювання та зберігання
Режими не конкурують, а складаються в шари: повне копіювання задає базу для відновлення, інкрементальне й диференціальне скорочують обсяг і вікно, безперервна архівація журналів визначає точку, на яку можна повернутися. Помилка — вибрати один варіант і чекати від нього всього одразу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повне копіювання | Первинна опора, база для ланцюжків, рідко змінювані бази | Довго читає диск, зростає обсяг і трафік на репозиторій |
| Інкрементальне копіювання | Великі бази з інтенсивним записом, потрібен частий бекап | Відновлення тягне весь ланцюжок; пошкодження сегмента ламає гілку |
| Диференціальне копіювання | Компроміс: ланцюжок коротший, ніж в інкрементів | Копія зростає між повними — при частому запуску виграш зникає |
| Безперервна архівація журналів | Потрібна точка відновлення в межах хвилин | Не замінює базову копію: журнали зберігають разом із нею |
| Зовнішня репліка | Швидке перемикання, розвантаження основного вузла | Логічну помилку не ловить — видалення поїде на репліку |
Локальний і зовнішній репозиторій
Локальний репозиторій швидший: копія лягає на сусідній том без мережі, вікно бекапу коротше. Але він помирає разом із хостом — при відмові сервера або шифруванні дисків зникає й копія.
Зовнішній репозиторій на окремому вузлі переживає відмову основного, і pgBackRest пише в два репозиторії паралельно: локальний залишається для швидкого відкату.
Зберігання та ротація
Правило зберігання фіксує, скільки повних копій і ланцюжків журналів лежить на диску, решта чиститься за розкладом — обсяг реєстру перестає зростати, а відкат на потрібну глибину зберігається.
Цілісність підтверджуємо відновленням на тестовий вузол, а не статусом «завдання завершилося успішно».
Налаштування pgBackRest: етапи впровадження та передачі
Роботу ведемо етапами: кожен наступний крок спирається на підтверджений результат попереднього, тому помилка видна до того, як зміни потраплять у робочу базу. Нижче — послідовність, за якою проходить впровадження.
Підготовка інфраструктури
- Аудит резервного копіювання. Дивимося, що копіюється зараз, куди пишуться дампи, скільки зберігаються, які обсяги й коли відкрито вікно обслуговування.
- Схема розміщення репозиторіїв. Вирішуємо, де живе репозиторій — локальний диск, окремий сервер або об’єктне сховище. Окремий репозиторій під кожну базу спрощує відновлення однієї бази, не зачіпаючи інші.
- Налаштування копіювання. Повний бекап за розкладом, інкрементальні між ними, безперервний архів WAL. Політика зберігання тримає копії за потрібний період, решта чиститься — репозиторій не зростає безкінечно.
- Розклад і контроль. Копіювання ставимо у вікно мінімального навантаження, перевіряємо завершення й налаштовуємо оповіщення: сигнал надходить при помилці або пропуску, а не під час наступного розбору відмови.
Перевірка на тестовому контурі
- Тестове відновлення. Розгортаємо копію на окремому контурі — до потрібної точки в часі, із заміром часу відновлення. Бекап вважається готовим лише після успішного відновлення.
- Регламент і передача в експлуатацію. Передаємо документацію: де лежать репозиторії, як запустити відновлення, як перевірити цілісність, кому надходить оповіщення. Фіксуємо, хто що робить при відмові — на нашій стороні або на стороні замовника.
Артефакти впровадження: конфігурації, регламенти, документація
На виході в інфраструктурі залишається не «налаштований сервер», а комплект артефактів, за якими копіювання далі супроводжує ваша команда без нас. Кожен пункт перевіряємо на прийманні: конфігурацію можна розгорнути на новому вузлі, регламент — прочитати й виконати в нічну зміну.
- Конфігурація pgBackRest: параметри репозиторію, розклад, шифрування та стиснення, прив’язка до кластера й правила виключень.
- Політика зберігання копій: скільки повних і проміжних наборів тримаємо, яка глибина за часом, як працює автоматичне очищення.
- Регламент відновлення: покроковий сценарій повного й точкового відновлення на окремий вузол, з обов’язковою перевіркою на тестовому контурі.
- Розмежування доступів: ролі на запис і читання репозиторію, окремий службовий користувач, обмеження доступу до ключів шифрування та журналів.
- Інструкція для чергової зміни: чек-лист ранкової перевірки, розбір типових оповіщень, порядок ескалації.
- Схема розміщення: де лежать копії, що переживає відмову основного майданчика, як влаштований архів.
- Журнал навчань: дати й результати тестових відновлень, заміряний час до працездатної бази.
Склад документації
Окремо передаємо опис архітектури копіювання, схему потоків даних, реєстр змін конфігурації та матрицю відповідальних. Документація зберігається поруч із кодом інфраструктури, а не в листуванні, — при зміні інженера контекст не втрачається.
Моніторинг та оповіщення
Метрики копіювання надходять у загальну систему моніторингу: тривалість, обсяг, статус останнього набору, відставання від розкладу. Алерти розділені за критичністю — відсутність даних у нічний час окремо від реального збою, щоб черговий не звик ігнорувати повідомлення.
Кейс: відновлення бази за хвилини замість годин
До переходу на потокове архівування відновлення бази після збою основного вузла займало від чотирьох до шести годин: піднімали останній нічний дамп, вручну докатували журнали, і кожна третя спроба закінчувалася розбіжністю даних.
Копії фізично існували, але їх ніхто не розгортав до аварії — перевірка йшла вже в момент інциденту, коли кожна хвилина простою складалася в зупинені замовлення.
Схему перебудували навколо безперервного архівування та повних копій із нарощуванням у pgBackRest: щоденна повна копія, інкрементальні між ними й постійне вивантаження журналів.
Раз на добу копія автоматично розгортається на тестовому контурі та звіряється за контрольними сумами — придатність відновлення підтверджується заздалегідь, а не за фактом відмови.
Що змінилося в повсякденній експлуатації
Час відновлення на тестовому контурі скоротився з чотирьох-шести годин до восьми-дванадцяти хвилин, частка успішних відновлень зросла з 60 до 100 відсотків: за весь час не пройшла одна спроба, і причина була в пошкодженому диску, а не в копії.
Зник цілий клас відмов — «резервна копія є, але нечитабельна»: биті та застарілі набори відсікаються автоматичною перевіркою і не доживають до аварії.
Відкат бази до попереднього стану став рутинною операцією на кілька хвилин, тому оновлення та міграції схеми перестали планувати під вихідні.
Чим відрізняється гарячий стенд від перевірюваної копії?
Репліка й копія вирішують різні завдання, і плутати їх дорого. Репліка — це безперервний потік змін: вона повторює стан основної бази майже без затримки й тримає сервіс доступним, якщо основний вузол випав.
Копія — знімок на конкретний момент, який лежить окремо від кластера й не залежить від того, що відбувається з даними прямо зараз.
Гарячий резерв виручає при відмові заліза: перемикання займає хвилини, застосунок продовжує працювати на читання й запис. Але він чесно повторює все, що йому передали, — масове видалення або помилкова правка поїде на стенд за секунди. Відкату в часі в репліки немає, тому захистом від людської помилки вона не є.
Копія для перевірок потрібна саме для цього: її розгортають в окремий контур і на ній відпрацьовують сценарії.
Відновлення на точку до збою, звірка цілісності, перевірка, що застосунок стартує й дані сходяться, — усе це робиться на ізольованому майданчику, не зачіпаючи робочий контур. Так регулярно підтверджується, що резерв справді робочий, а не просто існує.
pgBackRest у цій схемі закриває повний і накопичувальний набори копій: повернутися можна і на нічний знімок, і на потрібний момент між ними, без перезбирання кластера з нуля.
Вибір механізму відновлення залежить від класу збою: втрата вузла — сценарій перемикання на гарячий резерв, зіпсовані дані — відновлення з копії. Тому в проєкті зазвичай тримають обидва механізми, і в кожного свій порядок перевірки.
Перевірки відновлення, зберігання копій і доступи
Перевірюваність копій важливіша за їхню наявність. Ми не вважаємо резервне копіювання працюючим, поки не виконано пробний розворот на окремому стенді: розгортаємо повну копію, накочуємо журнальні сегменти до точки перед збоєм, звіряємо контрольні суми й цілісність індексів.
Прогін іде за розкладом, а результат потрапляє у звіт — видно, яка копія перевірена і на яку мітку часу з неї піднімається кластер.
Чим доводиться, що база справді відновиться?
Автоматичним прогоном відновлення на ізольованому стенді. Якщо розворот не проходить, надходить оповіщення з етапом, на якому він зупинився, — а не звіт «копіювання виконано успішно». Перевіряється й цілісність індексів, а не лише факт запуску кластера.
Що зі зберіганням, ротацією та строками копій?
Копії надходять в окреме сховище в іншому домені відмови, локальний диск під архів не переповнюється: pgBackRest пише потоково. Політика ротації задається явно — добові копії тримаємо місяць, тижневі квартал, місячні рік. Старі версії видаляються за розкладом, тому обсяг архіву перестає зростати лінійно.
Хто має доступ до копій і чи захищені вони?
Доступ до архіву не збігається з доступом до продуктивної бази: запис веде окремий обліковий запис, читання й розворот — окрема роль, ключі зберігаються поза репозиторієм. Копії шифруються на стороні джерела, тому винесений архів без ключа марний. Про відмову сховища або про закінчення строків дізнаємося з оповіщень, а не з розбору після збою.
Обговоримо задачу: що потрібно від інфраструктури на старті
Обговорення задачі копіювання починається не з вибору параметрів, а з інвентаризації того, що у вас уже розгорнуто. Нам потрібні вхідні дані з інфраструктури, щоб повернутися не із загальними словами, а з оцінкою обсягу робіт і планом впровадження під ваш контур. Нижче — те, що варто уточнити на першій розмові.
- Схема розміщення: скільки інстансів, чи є репліки й керовані кластери, які бази критичні для відновлення, а які можна піднімати за залишковим принципом.
- Обсяги та профіль змін: поточний розмір баз, добовий приріст, частка «гарячих» таблиць — від цього залежить тип резервних копій і частота їх зняття.
- До чого прагнемо щодо відновлення: скільки даних припустимо втратити і за який час система зобов’язана повернутися в стрій.
- Місце зберігання копій: локальний диск, мережеве сховище, об’єктне сховище, окремий майданчик — і чи є вимога тримати копії за межами основного контуру.
- Доступи й ролі: як видаються облікові дані під службові завдання, хто власник бакета або каталогу, як влаштована ротація ключів.
- Обмеження середовища: вікна обслуговування, правила мережевих фільтрів між сегментами, вимоги до шифрування під час передавання та на диску.
- Що вже працює: старі дампи, скрипти за розкладом, ручні вивантаження — їх доведеться або переносити, або акуратно виводити з експлуатації.
Зібравши це, ми фіксуємо обсяг робіт, порядок налаштування й перевірок і порядок передачі документації: конфігурації, опис політик зберігання, інструкцію з відновлення з перевіреним сценарієм відкату на тестовому контурі. Опишіть задачу й поточний стан — повернемося з оцінкою та планом.
