Налаштування резервного копіювання MongoDB через Percona Backup for MongoDB

Бекап MongoDB ламається: розбір через Percona Backup for MongoDB

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

Percona Backup for MongoDB закриває це фіксацією узгодженої точки на кожному вузлі набору реплік, від якої зміни можна відтворити до потрібного моменту.

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

Вікно резервного копіювання майже завжди перетинається з піком навантаження.

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

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

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

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

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

Percona Backup for MongoDB змінює обидві величини. Безперервний журнал операцій зберігається окремо від повної копії, тому цільова точка відновлення зсувається до хвилин перед збоєм, а не до останнього розкладу.

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

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

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

Логічний, фізичний і потоковий бекап: що вибрати

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

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

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

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

У Percona Backup for MongoDB всі чотири режими вмикаються одним набором команд, і їх можна поєднувати в одному розкладі:

Порядок впровадження: від аудиту до передачі регламентів

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

1. Аудит резервного копіювання. Збираємо поточний стан: чим знімаються копії, де лежать, хто відповідає, коли востаннє перевірялися. Окремо дивимося журнал збоїв — зазвичай знаходиться завдання, яке мовчки падає місяцями.
2. Вимоги до відновлення. Фіксуємо допустиму втрату даних і цільовий час підйому, чи потрібна точка відновлення на конкретний момент. Від цього залежить склад копій і глибина зберігання журналів операцій.
3. Схема зберігання копій. Вибираємо сховище, віддалене від продакшену, розкладаємо повні та інкрементальні знімки, задаємо строк життя і шифрування. Облікові записи для копіювання прав на зміну даних не отримують.
4. Розклад знімків. Налаштовуємо Percona Backup for MongoDB: агент на кожному вузлі, вікна поза піками навантаження, пріоритет реплік, повідомлення про невдачі. Копіювання не повинно конкурувати із записом у базу.
5. Тестове відновлення. Розгортаємо копію на окремому стенді й заміряємо реальний час. Звіряємо повноту даних, а не лише код завершення завдання.
6. Передача регламентів. Віддаємо документацію, ролі та чек-листи, налаштовуємо моніторинг, розбираємо ручний сценарій. Інженери замовника повинні вміти підняти базу без нас.

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

Артефакти: конфігурації, політики зберігання, регламенти

Контур на Percona Backup for MongoDB здається не працюючим скриптом, а набором артефактів, за якими чергова зміна і наступний інженер діють без автора налаштування. Усе перелічене залишається у замовника в репозиторії та внутрішній базі знань, з історією змін.

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

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

Як було влаштовано до

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

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

Що змінили

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

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

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

Що робити, якщо бекап уже налаштований саморобним скриптом?

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

Переходити лоб у лоб не потрібно. Спочатку Percona Backup for MongoDB ставиться поруч і починає знімати копії в окреме сховище, а попередні скрипти продовжують працювати за своїм розкладом.

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

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

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

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

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

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

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

Percona Backup for MongoDB читає журнал операцій, а не колекції повністю, тому копіювання не конкурує із записом застосунку.

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

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

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

Сховище копій вибирається за завданням: локальний том, мережева файлова система або об’єктне сховище — перемикання між ними задається профілем, без переробки самих правил знімання.

Що буде з копіюванням, якщо репліка відстала або вузол випав?

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

Обговоримо задачу: що потрібно для оцінки та плану робіт

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

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

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

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