Предположим, что в среду в 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 для обработки файлов бинарного журнала см. в разделе 7.5 «Восстановление по состоянию на определённый момент времени (инкрементное восстановление)».