Налаштування резервних копій MongoDB через mongodump із гарантією відновлення

Чому mongodump не рятує від втрати даних і як це виправити

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

До першого реального відновлення ніхто не заглядає всередину: бекап MongoDB зовні виглядає цілком здоровим.

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

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

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

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

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

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

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

Що дає регламентний бекап MongoDB: час, повнота, передбачуваність

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

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

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

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

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

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

Режими копіювання: mongodump, знімок тому та безперервна реплікація

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

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

Як режими поєднуються

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

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

Як ми впроваджуємо регламент бекапів: шість кроків від аудиту до передачі

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

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

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

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

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

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

Без цієї перевірки копія — це просто файл невідомої якості. 5. Моніторинг і оповіщення. Налаштовуємо контроль завершення завдань: дамп, що впав, має кричати, а не лежати в лозі. Додаємо перевірку свіжості останньої копії та вільного місця у сховищі. 6.

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

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

Скрипти, схеми, політики зберігання і регламент відновлення

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

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

Кейс: як регламент бекапів скоротив відновлення з доби до години

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

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

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

Метрики до і після

• Час підйому бази: з доби до години — за документованим порядком, без пошуку архіву.
• Перевірка копій: з нуля до 100% — проходить кожен дамп, а не вибірково.
• Обсяг реєстру: скоротився втричі при горизонті зберігання в місяць.
• Простій сервісу в інциденті: з ~20 годин до 40–60 хвилин.

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

Чим mongodump відрізняється від знімка тому та безперервної реплікації

mongodump обходить базу запитами на читання і складає документи у файли — це логічна копія.

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

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

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

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

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

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

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

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

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

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

Навантаження при копіюванні: чи просяде база?

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

Шардована база: чи збереться копія цілком?

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

Перевірка відновлення: як переконатися, що копія робоча?

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

Зберігання копій: скільки тримати і де?

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

Обговоримо задачу: повернемося з оцінкою і планом впровадження

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

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

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

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