Nehmen wir nun an, dass es am Mittwoch um 8:00 Uhr zu einem folgenschweren Absturz kommt, der eine Wiederherstellung aus den Sicherungen erfordert. Zu diesem Zweck stellen wir zunächst das letzte vollständige Backup (von Sonntag, 13:00 Uhr) wieder her. Da die vollständige Sicherungsdatei nichts anderes als eine Sammlung von SQL-Anweisungen ist, ist die Wiederherstellung sehr einfach:

shell> mysql < backup_sunday_1_PM.sql

An dieser Stelle sind die Daten auf dem Stand von Sonntag, 13:00 Uhr. Um nun die seitdem vorgenommenen Änderungen wiederherzustellen, müssen wir die inkrementellen Sicherungen verwenden, d. h. die Binärlogdateien gbichot2-bin.000007 und gbichot2-bin.000008. Besorgen Sie sich diese Dateien nun von dort, wo Sie sie gesichert hatten, und verarbeiten Sie ihren Inhalt wie folgt:

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

Wir haben nun die Daten auf dem Stand von Dienstag, 13:00 Uhr, wiederhergestellt. Noch aber fehlen die Daten zwischen diesem Zeitpunkt und dem des Absturzes. Um diese nicht zu verlieren, hätten wir den MySQL-Server so konfiguriert haben müssen, dass er seine MySQL-Binärlogs an einem sicheren Ort (RAID-Festplatten, SAN, usw.) speichert – nicht aber auf der Festplatte, wo er seine Datendateien speichert, damit die Logs sich im Schadensfalls nicht auf der zerstörten Festplatte befinden. (Zu diesem Zweck können wir den Server mit der Option --log-bin starten, die eine Position auf einem anderen physischen Gerät als demjenigen angibt, auf dem das Datenverzeichnis liegt. Auf diese Weise gehen die Logs nicht verloren, wenn das Gerät mit dem Datenverzeichnis zerstört wird.) Hätten wir das gemacht, dann hätten wir jetzt die Datei gbichot2-bin.000009 zur Hand und könnten sie einfach mit mysqlbinlog und mysql aufspielen, um die letzten Datenänderungen bis zum Moment des Absturzes verlustfrei wiederherzustellen.