Восстановление MySQL до точки времени с ZRM

Короткое описание и цель

ZRM for MySQL — надёжное решение для резервного копирования и восстановления MySQL (включая все движки хранения). В этом руководстве показано, как откатить базу данных к моменту времени (Point-in-Time Recovery, PITR) при ошибочном удалении данных пользователем.

В примере: в ~14:30 были добавлены 5 записей (tablespaces в исходном тексте называются таблицами/записями в MovieID). В 15:00 пользователь случайно удалил эти 5 записей. Последний полный бэкап был выполнен предыдущим вечером в 19:07. Задача — восстановить состояние базы на 14:45 (до удаления в 15:00).

Important: Для инкрементальных бэкапов требуется включённый бинарный лог (binary logging). Без него PITR невозможен.

Требования и предварительная подготовка

Доступ к серверу, где установлен ZRM и где хранятся бэкапы.
Права пользователя backup-user (или аналогичного) для выполнения чтения бэкапов и применения логов.
Включённый бинарный лог в /etc/my.cnf: под [mysqld] добавьте

log-bin=/var/lib/mysql/mysql-bin.log

и перезапустите MySQL.

Шаг 1 — Проверяем последний полный бэкап

Команда для просмотра информации о бэкапе (пример):

-bash-3.1# mysql-zrm-reporter -show restore-info --where backup-set=dailyrun

Пример вывода в исходном логе показывает, что последний полный бэкап (уровень 0) выполнен в Wed 18 Oct 2006 07:07:08 PM PDT и расположение указано в backup_directory.

Задача этого шага — убедиться, что есть пригодная базовая точка восстановления (full backup), от которой будут применяться инкременты.

Шаг 2 — Выполняем инкрементальный бэкап сейчас

Если с момента последнего полного бэкапа были изменения, создайте инкрементальный бэкап вручную, чтобы зафиксировать все изменения до момента восстановления:

-bash-3.1# mysql-zrm-scheduler --now --backup-set dailyrun --backup-level 1

Это гарантирует, что в наборе бэкапов присутствуют бинарные логи, охватывающие период между последним полным бэкапом и текущим временем.

Шаг 3 — Парсим бинарные логи из инкремента

ZRM может распарсить бинарные логи и показать список событий с отметками времени. Пример команды:

-bash-3.1# mysql-zrm --action parse-binlogs --source-directory /var/lib/mysql-zrm/dailyrun/20061019151937 --backup-set dailyrun

В выводе вы увидите набор записей с отметками времени (Timestamp), типами событий и SQL-запросами. В нашем примере отображены INSERT-ы в 14:34–14:36 и последующие DELETE, выполненные в 14:56 и др. Это даёт нам возможность выбрать точную метку времени для восстановления.

Примечание: внимательно проверьте временные метки и временную зону сервера при интерпретации Timestamp.

Шаг 4 — Восстановление до точки времени (stop-datetime)

Когда вы выбрали момент времени, до которого нужно откатиться (в примере 20061019144500 — 2010-06-10 14:45:00 в формате YYYYMMDDhhmmss), выполните команду восстановления с опцией –stop-datetime. Пример:

-bash-3.1# mysql-zrm --action restore --source-directory /var/lib/mysql-zrm/dailyrun/20061019151937 --backup-set dailyrun --stop-datetime "20061019144500"

Примерная последовательность действий, которую выполнит ZRM:

Распаковка/разархивация бэкапа.
Генерация временного файла с содержимым бинарных логов до stop-datetime: mysqlbinlog –stop-datetime=… –database=movies -r /tmp/NNqSZFZa8R …
Применение сгенерированного SQL через клиент mysql: source /tmp/NNqSZFZa8R;
Завершение восстановления и выключение MySQL для безопасной проверки.

Фрагмент лога восстановления (системные сообщения оставлены как в исходном примере) информирует о завершении и необходимости перезапуска сервера.

Шаг 5 — Перезапуск и верификация

Перезапустите MySQL-сервер.
Подключитесь к базе movies и выполните выборки, чтобы убедиться, что нужные записи/таблицы вернулись и что данные согласованы.
Проверьте целостность индексов и репликацию (если используется).

Если всё в порядке, восстановление успешно.

Критерии приёмки

База данных доступна после перезапуска MySQL.
Наличие вставленных записей, добавленных около 14:30, и отсутствие удалений, совершённых в 15:00.
Отсутствие ошибок в логе MySQL, связанных с импортированными данными.

Когда этот метод не сработает

Бинарный лог не включён или отсутствует за нужный период — тогда PITR невозможен.
Если база была физически повреждена и логические операции не покрывают потерянные файлы/структуры.
Миграции схемы или несовместимые изменения структуры, которые мешают применению бинарных логов к текущей базе.

Альтернативные подходы

Восстановление из свежего полного бэкапа и применение отдельных дампов таблиц, если доступны логические SQL-дампы.
Использование реплики (read replica) как источника для восстановления данных.
Восстановление на изолированную тестовую среду и экспорт/импорт только затронутых таблиц.

Быстрый SOP (чеклист действий для DBA)

Проверить последний полный бэкап: mysql-zrm-reporter.
Выполнить инкрементальный бэкап (если нужно сейчас): mysql-zrm-scheduler –now.
Распарсить бинарные логи: mysql-zrm –action parse-binlogs … и выбрать stop-datetime.
Выполнить восстановление с –stop-datetime.
Перезапустить MySQL и проверить данные.
Сообщить пользователю и зафиксировать инцидент.

План отката (если восстановление пошло не так)

Немедленно остановить сервер MySQL.
Восстановить из последней корректной точки (полного бэкапа + инкременты) в изолированную среду.
Сравнить различия и, при необходимости, применить другие наборы бинарных логов или выполнить частичную откатку через ручные SQL.

Контрольный список ролей

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

Короткий словарь

PITR: восстановление до заданной точки времени (Point-in-Time Recovery).
Binary log (binlog): журнал бинарных событий MySQL, используемый для репликации и PITR.
Full backup: полный бэкап базы данных (уровень 0).

Заключение

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