Настройка 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, порядок проверки восстановления на тестовом контуре и действия дежурной смены при сбое. Опишите задачу — вернёмся с оценкой и планом.