今日、データベースをバックアップするための非常に優れたアイデアを思いつきました: ダンプ ファイルを git リポジトリに置き、各ダンプをコミットして、最新のコピーと以前のバックアップに簡単にロールバックできるようにします。また、リポジトリのコピーを定期的に簡単にプルして、バックアップのバックアップとして自分のコンピューターにコピーを保持することもできます。それは間違いなく賢いように聞こえます。
ただし、巧妙なソリューションには根本的な欠陥がある場合があることは承知しています。git に mysqldump の差分を保存すると、どのような問題が発生する可能性がありますか? その価値はありますか？サーバー上に複数のデータベースのバックアップを作成し、別の場所に冗長コピーを保持するために、ほとんどの人は何をしますか?
通常、すべてのバックアップ (またはスナップショット) を永久に保持するわけではありません。Git リポジトリには、これまでに行ったすべてのチェックインが保持されます。古いリビジョンを削除することにした場合 (たとえば、1 か月前のリビジョンを週に 1 回に減らし、1 か月前のリビジョンを月に 1 回にするなど) git filter-branch、履歴全体を書き換える必要があります。次にgit gc、不要なリビジョンを削除します。
git の強みは、分散バージョン管理と複雑なパッチ/ブランチ ワークフロー (どちらもスナップショットやバックアップには当てはまらない) であることを考えると、より柔軟な履歴を持つ別の VCS を使用することを検討します。
このアプローチは私にはうまく聞こえます。自分の重要なデータのバックアップには Git を使用しています。
差分を保存していないことに注意してください。Git は、コミットごとにディレクトリの状態のスナップショットを効果的に保存します。2 つのコミットの差分を生成できますが、実際の格納メカニズムは差分とは関係ありません。
理論的にはこれでうまくいきますが、データベース ダンプが大きくなると問題が発生し始めます。
Git にはファイル サイズの厳密な制限はありませんが、最新のダンプの内容を以前にリポジトリに保存されたものと比較します。これには、両方のファイルを合計したサイズ以上のメモリが必要です。ファイルが100MB（または10MB）を超えると、非常に遅くなり始めると思います。
Git は、このタイプのファイル (つまり、ソース コードではなくビッグ データ ファイル) を処理するために作成されていないため、これは根本的に悪い考えだと思います。ただし、Dropbox などを使用してダンプを保存することもできます。これにより、バージョン履歴が保存されますが、効果的に差分できないファイル向けに調整されます。
MySQL (およびおそらく他のもの) を使用していて、バイナリ ログを有効にしている場合は、bin ログのディレクトリに git リポジトリを設定し、binlog に定期的に更新をコミットする戦略を立てることを検討してください。
MySQL では、データをデータベース上の任意のテーブルに変更するクエリが binlog に保存されます。コミットをデータベースの定期的なダンプと同期する場合は、バージョン管理された方法でデータを復元する必要があります。
正直なところ、MySQL のネイティブ ツールを使用する方がおそらくより良い解決策になると思いますが、ここで概説したことにより、MySQL データのバージョン管理が可能になります。