Предположим, что в среду в 8:00 произошел катастрофический непредвиденный выход из строя, требующий восстановления из резервных копий. Для восстановления сначала восстановим последнюю полную резервную копию (от воскресенья в 13:00). Файл полной резервной копии — это просто набор SQL-команд, поэтому его восстановление очень просто:

$> mysql < backup_sunday_1_PM.sql

В этот момент данные восстановлены до состояния на воскресенье в 13:00. Для восстановления изменений, внесенных с тех пор, необходимо использовать инкрементные резервные копии; то есть файлы двоичного журнала gbichot2-bin.000007 и gbichot2-bin.000008. Необходимо извлечь файлы, если необходимо, из места их резервного копирования, а затем обработать их содержимое следующим образом:

$> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

Теперь данные восстановлены до состояния на вторник в 13:00, но все еще отсутствуют изменения с этой даты до даты сбоя. Чтобы их не потерять, необходимо было настроить сервер MySQL на сохранение двоичных журналов MySQL в безопасном месте (диски RAID, SAN и т. д.) отличном от места хранения файлов данных, чтобы эти журналы не находились на поврежденном диске. (То есть, мы можем запустить сервер с опцией --log-bin, которая указывает местоположение на другом физическом устройстве, отличном от устройства, на котором находится директория данных. Таким образом, журналы остаются в безопасности, даже если устройство, содержащее директорию, потеряно.) Если бы мы это сделали, у нас был бы файл gbichot2-bin.000009 (и любые последующие файлы), и мы могли бы применить их с помощью mysqlbinlog и mysql, чтобы восстановить последние изменения данных без потерь до момента сбоя:

$> mysqlbinlog gbichot2-bin.000009 ... | mysql

Дополнительную информацию об использовании mysqlbinlog для обработки двоичных журналов см. в разделе 9.5 «Восстановление по состоянию на определенный момент времени (инкрементное восстановление)».