バイナリログを有効にしてからバックアップすることで、増分バックアップをシミュレートできます。 「バイナリログを有効にして増分バックアップを作成する」の http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html を参照してください。
InnoDBを使用している場合は、Xtrabackup（Perconaによる）をチェックアウトします。それは増分を行うことができます。
http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup:incremental?rev=1289183209
乾杯
https://sourceforge.net/projects/mysqlincrementalbackup/ スクリプトを確認します。 MyISAMおよびInnodbの増分バックアップソリューション。
私はバイナリログを使用していますが、それらは究極の解決策ではなく、自分もスナップショットに依存している傾向があります。
これには主に2つの理由があります。
- Binlogsはすべての変更を保存します。 1週間分のバイナリログは、1週間おきの2つのスナップショットの違いよりも大幅に大きくなる可能性があります。唯一の救済は、binlogが十分に圧縮する傾向があることです（通常は10％をはるかに下回ります）。
- 監査または前に戻る必要がある場合、古いスナップショットに対してbinlogを再生すると非常に長い時間がかかり、binlogが大きいとエラーが発生する可能性が高くなるため、定期的なスナップショットが必要です。
最近、多数のスナップショットを作成しましたが、圧縮も差分もありませんでした。私はdiffを試してみましたが、コンテキストがないなどのオプションを使用しても、結果のdiffが大きくなることがわかりました。
すべての代替案を試さずに、私が見つけた最高のものはrdiffでした。これにより、私にとってサイズの約5％に縮小され、その後xzで1％ゾーンに圧縮されました。
Rdiff署名ファイルはハッシュコレクション（ランダムデータと同じ）であるため、うまく圧縮されませんが、相互に圧縮すると良い結果が得られます。
多くの場合、このようなソリューションは必要ありません。ほとんどの場合、障害が発生した場合、最新のイメージを含むデータベースを保存し、できるだけ早く更新する必要があります。
ただし、多くのアカウンティング、監査、デバッグなどを必要とする複雑なシステム（ブログよりも重要なもの）がある場合は、スナップショットの効率的なストレージが重要になります。