Как найти разрыв цепочки инкрементальных бэкапов MariaDB

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

Совпадение LSN — необходимая проверка, но не доказательство восстановления. Окончательный результат подтверждают успешная подготовка комплекта, запуск отдельной тестовой БД и проверка нужных данных.

1. Соберите паспорт цепочки

Инструкция относится к физическим копиям mariadb-backup, прежде называвшегося mariabackup. Для SQL-дампов и снимков провайдера порядок другой.

До любых изменений выпишите для полной копии и каждого приращения:

• идентификатор исходной БД и задания, каталог или версию объекта в хранилище;
• время завершения с часовым поясом и результат задания;
• версию сервера и инструмента, родительский бэкап;
• backup_type, from_lsn, to_lsn и last_lsn.

Метаданные находятся в xtrabackup_checkpoints для MariaDB до 11.1, а начиная с 11.1 — в mariadb_backup_checkpoints. to_lsn обозначает последний checkpoint, last_lsn — последнюю прочитанную позицию redo-журнала; для стыковки не подменяйте одно другим. Названия и поля описаны в справочнике файлов MariaDB Backup.

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

2. Сверьте зависимости, а не названия папок

Для линейной цепочки следующий инкремент создают от предыдущего через --incremental-basedir. При подготовке приращения применяют к полной базе по порядку — это схема из руководства по инкрементальным копиям.

Условный пример, числа приведены только для объяснения:

| Копия | from_lsn | to_lsn | | --- | ---: | ---: | | full | 0 | 1000 | | inc1 | 1000 | 1500 | | inc3 | 1800 | 2200 |

После inc1 нет перехода от 1500 к 1800. Свежая дата inc3 не позволяет применить его сразу: нужно найти недостающее звено с нужным диапазоном и подтвердить его происхождение.

Если значения не стыкуются

• Следующий from_lsn больше текущего to_lsn. Ищите пропущенное приращение: незавершённую выгрузку, удалённую версию объекта, ошибку задания или другую папку.
• Следующий from_lsn меньше текущего to_lsn. Возможно, выбран другой родитель или приращения созданы от одной полной базы. Сверьте журнал создания; их нельзя автоматически считать последовательными.
• Значения равны, но исходная БД другая. Такой комплект не становится совместимым: LSN не является глобальным идентификатором сервера.
• Метаданных нет или они противоречат журналу. Считайте связь неподтверждённой; имя файла и время загрузки её не заменяют.

Не исправляйте LSN в метаданных ради совпадения. Вручную заданный неверный --incremental-lsn может сделать копию непригодной; это ограничение прямо отмечено в справочнике параметров.

3. Проверьте сборку на рабочих копиях

Сохраните исходный комплект неизменным. Подготовка меняет базовый каталог, поэтому работайте с отдельной копией полной базы и копиями приращений; заранее проверьте свободное место и совместимость версий.

Пример для подтверждённой цепочки full → inc1 → inc2, где все каталоги находятся на изолированном стенде:

mariadb-backup --prepare --target-dir=/restore-work/full
mariadb-backup --prepare --target-dir=/restore-work/full --incremental-dir=/restore-work/inc1
mariadb-backup --prepare --target-dir=/restore-work/full --incremental-dir=/restore-work/inc2

Это подготовка файлов, а не восстановление поверх работающего сервера. После каждого шага проверяйте код завершения и журнал; при ошибке остановитесь и сохраните диагностику, не продолжайте цепочку вслепую.

Перед переносом подготовленной копии тестовый сервер MariaDB должен быть остановлен, а его отдельный datadir — пуст. Эти условия приведены в инструкции полного восстановления. Не используйте рабочий каталог production и не запускайте рядом с тестовой БД реальные рассылки, оплаты и фоновые задания.

4. Зафиксируйте последнюю проверенную точку

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

В протокол внесите состав цепочки, выбранную точку, версии, результаты подготовки и проверки данных. Разделяйте выводы: «LSN стыкуются», «подготовка прошла», «тестовая БД запущена», «нужные записи проверены». Общий порядок проверки приложения есть в инструкции пробного восстановления бэкапа.

Web-Puls помогает наблюдать за доступностью публичного сайта после восстановления, но HTTP-мониторинг не проверяет цепочку бэкапов. Если связь копий установить не удалось, отправьте заявку на диагностику: укажите сайт, версии и обезличенное описание разрыва без архивов, ключей и паролей; команда оценит задачу и согласует формат работ.