Налаштування резервного копіювання PostgreSQL через Barman

Barman PostgreSQL резервне копіювання: чому відновлення зривається

Класична картина: перевірка конфігурації повертає ok, копії йдуть за розкладом, звіти зелені — налаштування barman вважається завершеним.

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

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

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

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

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

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

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

Вимірюваний ефект керованого резервного копіювання

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

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

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

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

Якщо показник погіршився, розбираємо причину: зріс обсяг бази, змінилася схема зберігання або зламався розклад запуску.

Режими роботи та обмеження різних схем копіювання

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

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

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

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

Порядок впровадження: від обстеження до передачі в експлуатацію

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

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

1. Обстеження кластерів: версії, обсяги, темп змін, вікна обслуговування, вимоги до точки та часу відновлення.
2. Схема резервування: де розміщуємо сервер резервного копіювання, куди пишуться копії, глибина зберігання, режим архівації журналів і потокової передачі.
3. Налаштування: підключення серверів, розклади повних та інкрементальних копій, політика зберігання, повідомлення про помилки архівації.
4. Тестове відновлення: розгортаємо копію на окремому інстансі, заміряємо час до робочого стану й перевіряємо відкат на точку в часі.
5. Регламент копіювання: розклади, відповідальні, порядок дій при збої, перевірка цілісності та ротація копій.
6. Моніторинг і передача в експлуатацію: сповіщення на збій архівації, панель стану, документація, навчання команди.

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

Конфігурації, регламенти та документація на виході

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

Інженер, який не брав участі в налаштуванні, має за цими матеріалами підняти відновлення на тестовому контурі й отримати той самий результат.

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

Передаємо разом із розбором: проходимо по кожному артефакту, відповідаємо на питання, фіксуємо власників. Далі команда веде систему сама.

Кейс: відновлення за хвилини замість кількох годин

До: дамп, який ніхто не розгортав

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

Журнали передзапису архівувалися нерегулярно, тому відновлення на точку перед збоєм не існувало — тільки «останній успішний дамп», тобто втрата даних за добу й більше.

Після: потокова копія та регулярні навчання

Підняли Barman окремим сервером: він знімає повні копії потоком, безперервно приймає журнальні сегменти й зберігає їх поза основним кластером.

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

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

Час відновлення скоротився з приблизно п'яти годин до 12–18 хвилин разом із перенесенням і запуском. Частка перевірених копій зросла з нуля до 100% — кожна повна копія проходить розворот на стенді до потрапляння в ротацію.

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

Що робити, якщо Barman уже розгорнуто, але копії не перевірялися?

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

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

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

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

Потім — перегляд схеми копіювання.

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

Окрема частина — регламент: перевірка відновлення за розкладом, а не час від часу. Автоматичний розворот на тестовий контур, замір часу до готовності бази, сповіщення при збої архівації WAL або копії, звіт про стан по кожному серверу.

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

Технічні питання щодо зберігання та перевірки копій

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

Скільки місця займуть копії?

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

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

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

Обговорімо вашу схему резервування та повернемося з планом

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

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