Налаштування резервного копіювання БД: PostgreSQL, MySQL, MongoDB

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

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

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

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

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

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

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

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

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

Що змінюється після впровадження: строки відновлення та простої

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

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

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

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

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

Порівняння підходів до резервного копіювання: що вибрати

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

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

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

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

Етапи впровадження: від схеми даних до передачі регламентів

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

1. Аудит баз даних. Інвентаризація всіх екземплярів PostgreSQL, MySQL і MongoDB: обсяги, швидкість зростання, профіль навантаження, критичність контуру. Тут же з’ясовується, що резервується за інерцією, а що не резервується взагалі.
2. Цільові показники. За кожним контуром фіксуємо допустиму втрату даних і цільовий час відновлення — від них залежить частота повних та інкрементальних копій і глибина архівації журналів.
3. Схема зберігання копій. Де лежать копії, строк зберігання, правила ротації, шифрування й розділення доступів: обліковий запис резервного копіювання не повинен мати прав видаляти продакшен.
4. Налаштування й автоматизація. Розклади, повні та інкрементальні копії, безперервна архівація журналів, моніторинг завдань з алертами на помилку або пропуск запуску.
5. Тестове відновлення. Розгортаємо копії на окремому стенді, заміряємо фактичний час відновлення й перевіряємо цілісність даних на вибраний момент, а не наявність файлу в сховищі.
6. Регламент відновлення. Покроковий порядок дій, відповідальні, точки ухвалення рішень; навчання за ним, щоб документ перевірявся практикою, а не лежав у документації.
7. Перегляд схеми. При зростанні обсягів або зміні архітектури розклади й глибина зберігання переглядаються, інакше вимоги щодо втрати даних тихо перестають виконуватися.

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

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

Комплект оновлюємо за кожної зміни контуру — інакше документація розходиться з реальністю за пару місяців.

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

Приклад із практики: відновлення за хвилини замість годин

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

Перевели бази на безперервне архівування журналів попереднього запису PostgreSQL плюс базову копію раз на добу та інкрементальні кожні 15 хвилин.

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

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

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

Метрики після: точка відновлення — 5 хвилин замість доби, підйом — 12-18 хвилин проти 4-6 годин, частка перевірених копій — 100%. Відкат можливий на будь-який момент у межах місяця, а не лише на останню ніч. У регламент додали щомісячну навчальну тривогу: відновлення на стенд без попередження команди.

Що робити, якщо база вже працює в кластері з реплікацією?

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

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

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

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

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

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

Технічні сумніви: обсяги копій, шифрування й доступи

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

Навантаження визначає джерело копії, а не час запуску. Зняття з вторинної репліки або знімка файлової системи не відбирає ресурси в основної бази: читання йде на окремому вузлі.

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

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

Копії займуть весь диск?

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

Хто отримає доступ до копій?

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

Обговоримо задачу: надішліть схему бази й поточний регламент

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

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

Що надіслати для оцінки:

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

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

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

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