Настройка 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 не конкурирует с записью клиентов.
• Требования к восстановлению: допустимая потеря последних минут данных и целевое время подъёма копии до рабочего состояния.
• Что уже настроено: текущие скрипты, расписание, место хранения, были ли попытки восстановления и чем они заканчивались.
• Ограничения среды: правила безопасности, шифрование копий, где разрешено хранить дампы и у кого есть к ним доступ.
• Контур восстановления: тот же кластер, резервная зона или отдельный стенд — и кто инициирует восстановление.

Достаточно описать задачу своими словами: обсудим задачу, зафиксируем входные данные, согласуем сроки этапов и вернёмся с оценкой работ и планом внедрения, где критерии приёмки определены до старта.