(前セクションの続きです。) ここで、水曜日の午前 8 時に、バックアップを使用してリカバリを行う必要があるクラッシュが発生したとします。まず、前回のフル バックアップ (日曜午後 1 時のもの) をリストアします。フル バックアップのファイルは SQL ステートメントのセットであるため、リストアは簡単にできます。

shell> mysql < backup_sunday_1_PM.sql

ここで、データが日曜午後 1 時の時点での状態になります (リストア した。) 次に、これ以降に発生した変更についてもリストアします。つまり、インクリメント バックアップであるバイナリ ログ ファイル、gbichot2-bin.000007 と gbichot2-bin.000008 を使用します。必要に応じて、このファイルをバックアップしたところからフェッチして、その内容を次にように処理します。

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

この時点で、データは火曜午後 1 時点の状態になります (リカバリできました。)　しかし、まだクラッシュするまでのデータ (変更) が欠けています。まず、リカバリしたものを失くさないために保存します。このときは、MySQL サーバが、MySQL バイナリ ログで安全な場所に保存しなければなりません。RAID ディスク、SAN など、データ ファイルとは別の場所 (壊れていないディスク) に保管してください。この状態で、--log-bin を使用してサーバを起動すると、物理的には異なるデバイスのデータ ディレクトリから MySQL のログを立ち上げることができます。ここまでの作業 (リカバリしたものを保存) が完了したら、gbichot2-bin.000009 ファイル (クラッシュするまでのログ) で、mysqlbinlog と mysql を適用して、クラッシュした時点までのデータ変更を失うことなく、最新のデータ変更をリストアできます。