GitでMySQLデータベースをバックアップするのは良い考えですか？

アプリケーションのバックアップ状況を改善しようとしています。DjangoアプリケーションとMySQLデータベースがあります。Gitでデータベースをバックアップすることを提案する記事を読みました。

一方で、データとコードのコピーを同期させておくので気に入っています。

しかし、Gitはデータ用ではなくコード用に設計されています。そのため、コミットごとにMySQLダンプを比較する多くの余分な作業を行うことになります。保存する前にファイルを圧縮しても、gitはファイルを差分しますか？

（現在、ダンプファイルは100MB非圧縮、bzip圧縮時は5.7MBです。）

編集：コードとデータベーススキーマの定義は既にGitにあります。これは実際にバックアップすることを心配しているデータです。

データを失う前に、この質問にシステム管理者の視点を紹介してみましょう。

バックアップを作成する理由は1つしかありません。何か問題が発生した場合に必ず復元できるようにすることです。そのため、適切なバックアップシステムには、gitが合理的に処理できる範囲をはるかに超える要件があります。

以下は、gitでデータベースをバックアップしようとする際に予測できる問題の一部です。

• リポジトリは「バックアップ」ごとに劇的に成長します。以来gitの店舗全体のオブジェクト（圧縮されたとはいえ）、その後、後でそれらをdiffを（例えば、あなたが実行してgit gc）、および履歴を保持永遠に、あなたが実際に必要とする、あるいはしたくないという保存された非常に大量のデータを持っています。ディスク容量を節約するため、または法的理由のために行うバックアップの量または保持期間を制限する必要があるかもしれませんが、多くの付随的な損害なしにgitリポジトリから古いリビジョンを削除することは困難です。
• 復元は、リポジトリに保存した特定の時点に限定されます。また、データが非常に大きいため、ささいな時間を超えて戻るのが遅い場合があります。この目的のために設計されたバックアップシステムは、格納されるデータの量を制限する一方で、より詳細な粒度を提供し、リストアを高速化し、災害発生時のダウンタイムを削減します。データベース対応のバックアップソリューション（例）では、継続的なバックアップも提供できるため、単一のトランザクションが失われることはありません。
• コミットも同様に遅くなり、データベースが大きくなるにつれて遅くなります。gitは、本質的にはfilesystemにマッピングされるキーと値のデータストアであり、したがって、基礎となるファイルシステムのパフォーマンス特性の影響を受けることに注意してください。この期間が最終的にバックアップ間隔を超える可能性があり、その時点でSLAを満たすことができなくなります。また、適切なバックアップシステムは、データが大きくなるにつれてバックアップに時間がかかりますが、構成する保持ポリシーに基づいて独自のサイズを自動的に管理するため、それほど劇的ではありません。

データベースダンプをgitに入れた場合、データベースダンプでできることは明らかにいくつかありますが、全体として、バックアップを保持する目的でそれを推奨することはできません。特に、バックアップシステムは広く利用されており（多くはオープンソースでもあります）、データを安全に保ち、可能な限り迅速に復旧できるようにするのに非常に優れています。

私の2セント：私はそれが良いアイデアだとは思わない。GITは、「異なる時点でファイルのセットのスナップショットを保存する」のような何かをするので、あなたができる完全にそのような何かのためにGITを使用していますが、それはあなたが意味するものではありませんはず。GITはソースコードを格納するように設計されているため、その機能のほとんどが失われ、わずかな利便性のために多くのパフォーマンスを犠牲にすることになります。

これについて考えている主な理由は、「データとコードのコピーを同期させる」ことであり、これは、コードのバージョン2.0がバージョン1.0とは異なるデータベーススキーマを必要とすることを心配していることを意味します。より簡単なソリューションはCREATE、Gitリポジトリのソースコードに沿って、データベーススキーマをステートメント付きのSQLスクリプトのセットとして保存することです。次に、インストール手順の一部として、以前にインストールしたデータベースサーバーでこれらのスクリプトを実行します。

これらの単なる-dテーブルの実際の内容はCREATE、ソースコードのバージョンとは関係ありません。サーバーAとサーバーBにバージョン1.0のソフトウェアをインストールするとします。これらは、さまざまなチームによってさまざまな企業で使用されています。スキーマがまったく同じであっても、数週間後、テーブルの内容は大きく異なります。

データベースの内容をバックアップしたいので、バックアップダンプが属するソフトウェアの現在のバージョンでバックアップダンプをタグ付けするバックアップスクリプトを使用することをお勧めします。スクリプトはGITリポジトリにある必要があります（そのため、ソースコードバージョン文字列にアクセスできます）が、ダンプ自体はバージョン管理システムに属していません。

編集：

質問の動機付けとなった元の投稿を読んだ後、これはさらに疑わしいアイデアだと思います。重要な点は、mysqldumpコマンドがDBの現在の状態を一連のSQL INSERTステートメントに変換し、GITがそれらを比較して更新されたテーブル行のみを取得できることです。

mysqldumpこれがあるため、一部では、音でのバックアップの方法のいずれかのMySQLのマニュアルに記載されています。GITの部分は、データベースサーバーがMySQLを含むクラッシュから回復するためにトランザクションログを保持していることに気付かない場所です。され、このログを使用して、あなたのデータベースの増分バックアップを作成する必要があることを、GIT、ありません。これには、何よりもまず、GITリポジトリを無限に拡張するのではなく、リカバリ後にログをローテーションまたはフラッシュできるという利点があります...

個人的には、ソース管理バージョンシステムを使用してバックアップファイルを保存することはお勧めしません。GITバージョン管理は、バイナリやMySQLバックアップダンプファイルのようなダンプファイル用ではなく、データファイル用に設計されているためです。あなたがそれを行うことができるという事実は、あなたがそれをするべきであることを自動的に意味するものではありません。さらに、リポジトリは、新しいコミットごとに新しいデータベースのバックアップを考慮して、大量のハードディスク容量を使用して劇的に成長し、GITのパフォーマンスが影響を受け、ソース管理システムが遅くなります。私にとっては、バックアップ戦略を実行し、コード内の何かがおかしくなったときにデータベースを復元する必要がある場合は常にバックアップファイルを用意しておくことは問題ありませんが、ソース管理ツールはバイナリデータを保存しません。

これらの理由から、1日目と2日目のバックアップファイルを保存し、2つのバックアップファイルの違いを確認するユーティリティはありません。多くの余分で無駄な作業が必要になります。新しいコードをコミットするときにデータベースバックアップを保存するためにGITを使用する代わりに、日付と時刻で区切られた別のパスにデータベースバックアップを保存し、タグを使用して各バージョン用に作成された新しいデータベースバックアップへの参照をコードに挿入します。誰かがすでに提案したように。

データベースのバックアップとGITに関する最後のメモ：データベース管理者は、一部のデータが失われたためにデータベースを復元する必要がある場合、1日目のバックアップファイルと2日目のバックアップファイルの違いを確認する必要はありません。エラーやデータの損失なしにデータベースを復元できるようになり、ダウンタイムを削減する最後のバックアップファイル。実際、データベース管理者のタスクは、何らかの理由でシステムに障害が発生した場合に、できるだけ早くデータを復旧できるようにすることです。コミットにリンクされたGITにデータベースバックアップを保存する場合、バックアップはGITリポジトリに保存した特定の時点に限定され、ダウンタイムを削減するため、データベース管理者がデータをすばやく復元することはできません。システムの

次に、GITを使用してバックアップを保存することはお勧めしません。代わりに優れたバックアップソフトウェアソリューション（ここにいくつかあります）を使用します。これにより、よりきめ細かくなり、データを安全かつ安全に保ち、災害時のデータ復旧が簡単かつ迅速に。

Git、特にデータベースにバイナリデータを保存しないでください。
コードの変更とデータベースDMLの変更はまったく異なります。

MySQLとOracleは、任意の時点に復元する目的でアーカイブログを書き込むことができます。それらのログを安全な場所にバックアップするだけで大​​丈夫です。

Gitを使用してこれらの「アーカイブログ」をバックアップすることは意味がありません。実稼働環境のアーカイブログはかなり重いため、定期的な完全バックアップを作成した後、削除する必要があります。また、それらをgitに入れることは無意味です-それらはある意味で既にリポジトリです。