MariaDB Backup: настройка горячего резервного копирования под ключ

MariaDB backup: где ломается горячее копирование

Горячая копия снимается без остановки сервиса — и ломается не в момент копирования, а в момент восстановления. Типовой сценарий: дампер для консистентности на короткое время берёт блокировку таблиц на запись. На базе в десятки гигабайт это минуты, когда приложение не пишет: очередь соединений растёт, часть запросов падает по таймауту.

Как только блокировку снимают, чтобы не ронять сервис, копия становится рассогласованной. Горячее резервное копирование MariaDB в режиме одной транзакции (--single-transaction) даёт согласованный срез только для транзакционных таблиц, а в одной схеме соседствуют таблицы без транзакций — они читаются в другой момент. В копии появляются заказы без позиций и внешние ключи в пустоту: восстановление проходит формально, а данные не сходятся.

Вторая ловушка — копия не помнит точку, на которую её сняли. Для восстановления на произвольный момент нужна согласованная позиция в журнале изменений; без неё воспроизведение событий уводит базу не туда. Долгое снятие попутно раздувает журнал: место на диске заканчивается раньше, чем копия готова, и падает уже рабочий сервер.

И главное: копия, которую ни разу не восстанавливали, — не резерв, а архив неизвестного качества. Проверка целостности резервной копии делается только полным прогоном восстановления на отдельном стенде: сверка контрольных сумм ключевых таблиц, сходимость строк и внешних связей, чистый журнал ошибок после старта. Разбираем, как это закрывается — от выбора режима снятия до регламента регулярных проверок.

Что даёт горячее резервное копирование без остановки сервиса

Окно недоступности схлопывается до секунд

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

Восстановление за десятки минут

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

Копия согласована на момент снятия

Задача не просто сохранить таблицы, а получить непротиворечивый срез: данные и журнал соответствуют одной и той же точке. Без этого восстановление даёт битые внешние ключи и расхождения между таблицами, которые потом ищут вручную. Согласованность настраивается на уровне процедуры, а не проверяется глазами дежурного, — поэтому копия пригодна к использованию сразу.

Контроль копий без ручных проверок

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

Сравнение подходов: логический дамп, снимок тома, реплика

Три подхода закрывают разные задачи, и выбор диктует не привычка команды, а объём базы, допустимое окно и требуемая точка восстановления. Логический дамп базы данных читается глазами, переносится между версиями и платформами, но на больших объёмах растягивается на часы и заметно греет диск. Снимок тома хранилища снимается за секунды, однако без предварительной согласованной паузы записи даёт рассогласованный набор страниц, который может просто не подняться.

Реплика для резервирования переносит нагрузку с основной базы: копию снимают с отстающего узла, боевой сервер этого не замечает. Инкрементное резервное копирование дополняет любую из схем — ежедневный полный набор на десятки гигабайт не влезает ни в окно, ни в хранилище.

На практике схемы комбинируют: полный набор раз в неделю, ежедневный инкремент, а непрерывная запись бинарного лога даёт точечное восстановление на момент времени — откат не к ночной копии, а к минуте перед сбоем. Какая связка подойдёт вам, зависит от объёма и допустимого окна простоя — это и разбираем на старте.

Порядок внедрения: от аудита до передачи в эксплуатацию

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

1. Аудит резервного копирования. Разбираем текущие задания и их фактический результат, скорость роста базы, запас по месту, права на чтение с реплик. Фиксируем риски: съём с мастера мешает записи, целостность не проверяется, единственная копия лежит на том же томе, что и данные.
2. Схема резервирования базы. Подбираем комбинацию: полный снимок mariabackup, инкременты по изменённым страницам и бинарные логи для восстановления на точку во времени. Согласуем целевые точки и время восстановления, глубину хранения и выгрузку за пределы сервера.
3. Настройка расписания копий. Раскладываем задания по окнам низкой нагрузки и снимаем копии с реплики, чтобы не конкурировать с мастером за дисковые операции. Задаём ротацию, контроль кода возврата задания и оповещение при сбое.
4. Тестовое восстановление. Разворачиваем копии на отдельном стенде и замеряем реальное время восстановления — базы целиком и отдельной таблицы. Сверяем контрольные суммы и прогоняем проверки на восстановленных данных: ошибки в схеме всплывают здесь, а не во время аварии.
5. Передача в эксплуатацию. Отдаём регламенты: что и когда копируется, где хранится, кто и как восстанавливает, как читать оповещения мониторинга. Проводим учебное восстановление силами вашей дежурной смены и остаёмся на поддержке по графику.

Комплект на выходе: конфигурации, схемы, регламенты

Комплект собирается так, чтобы дежурная смена действовала по нему без нас: конфигурации, которые уже работают на стендах и в боевом контуре, плюс документы, объясняющие каждое принятое решение. Ниже — что именно остаётся у вашей команды после сдачи.

• Рабочие конфигурации резервного копирования по каждой базе: расписание, набор объектов, режим снятия копий без остановки записи, параметры сжатия и шифрования — одинаковый набор проходит и по стендам, и по боевой среде.
• Схема резервного контура: какие узлы участвуют, где размещаются копии, как разделены основная и внешняя площадки, что происходит при отказе одного из хранилищ.
• Политика хранения копий: глубина по типам — ежедневные, недельные, месячные, правила продления и удаления, привязка к регламентным окнам, чтобы объём реестра не рос бесконтрольно.
• Регламент восстановления базы: пошаговый порядок с точками полного и частичного восстановления, ожидаемое время возврата в строй и обязательная сверка данных после подъёма.
• Роли доступа к копиям и журнал операций: кто снимает копию, кто читает, кто восстанавливает; доступ к боевым данным вынесен в отдельный контур.
• Документация по резервному копированию: описания, схемы и контрольные списки лежат в репозитории рядом с конфигурациями и версионируются вместе с ними.
• Журналы проверок восстановления: даты, что поднимали, расхождения, фактическое время — доказательство, что копия живая, а не просто файл в хранилище.

Кейс: восстановление базы после отказа узла

Что было до изменений

У заказчика — интернет-магазин с интенсивной записью в MariaDB. Ночной дамп снимался с того же узла, что обслуживал нагрузку, ложился на соседний раздел и ни разу не восстанавливался. Проверку пригодности проходила примерно половина копий: часть обрывалась на выгрузке, часть не сходилась по контрольным суммам — узнавали об этом в момент аварии. Когда узел отказал, восстановились до копии прошлой ночи: потеряли около суток заказов и правок каталога, а подъём занял больше шести часов.

Что изменили и что стало

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

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

Чем отличается MariaDB backup от репликации?

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

DELETE без условия или UPDATE с забытым WHERE размножится по всем репликам за секунды. Отложенная реплика с задержкой в несколько часов даёт окно на спасение, но только если ошибку заметили внутри этого окна, и не защищает от порчи, начавшейся раньше.

Восстановление на момент времени возможно только из копии. Снимок MariaDB, снятый mariadb-backup на работающем сервере, плюс бинарные логи дают полную историю изменений. Мы разворачиваем снимок и проигрываем логи до нужной позиции или метки времени — до запроса, который всё сломал. Так работает откат удалённых данных: база возвращается в состояние на секунду раньше сбоя.

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

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

Частые технические вопросы по резервному копированию

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

Нужно ли останавливать приложение?

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

Сколько места займут копии?

Полная копия сопоставима с объёмом данных, инкремент — только изменённые страницы. Цепочку сворачиваем в новую полную, старые версии вытесняем по сроку хранения — рост объёма предсказуем.

Как проверить, что копия пригодна?

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

У нас уже настроено резервирование — что менять?

Смотрим, что делается сейчас: дамп по расписанию, снимок средствами виртуализации или реплика без журналов. Отвечаем, из какой копии база восстановится за приемлемое время; если ясности нет — добавляем проверку пригодности и управляемое хранение.

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

Обсуждение задачи с инженером начинается с фактов о контуре, а не с пожеланий — иначе оценка превращается в вилку. Ниже вводные для расчёта работ, которые снимают большую часть вопросов на старте. Если чего-то не хватает, подскажем, какой командой это посмотреть в работающей системе.

• Топология: одиночный сервер, ведущий со слейвами или кластер — от этого зависит, снимаем мы логический дамп или физическую копию.
• Объём баз и профиль записи: размер данных, суточная доля изменений, окна минимальной активности.
• Цели восстановления: на какой момент времени допустимо потерять данные и за какое время база обязана вернуться в строй.
• Требования к консистентности: нужен согласованный снимок всех таблиц или достаточно отката по журналу на нужную секунду.
• Куда складывать копии: локальный диск, сетевое хранилище или отдельный контур, с политикой хранения и глубиной ротации.
• Доступы и шифрование: где хранятся ключи, кто получает доступ к копиям, требуется ли аудит операций.
• Что уже есть: текущие регламенты, скрипты, расписания и стенд, на котором можно отработать восстановление.

После этого мы возвращаемся с оценкой работ по резервному копированию и планом внедрения резервирования: состав задач, порядок, точки проверки и что потребуется с вашей стороны. Отдельно проговорим сопровождение резервного контура — мониторинг, ротацию копий и регулярные учения по восстановлению, чтобы копии не оставались «на бумаге».