バージョン管理ソフトウェアを介してファイルシステムをバックアップすると、どのような利点がありますか？

バージョン管理とバックアップは、さまざまな管理レベルでさまざまな目的に使用されます。プロジェクトは構成管理およびバージョン管理システムを使用してコードを制御および管理し、システムレベルでは管理者（IT部門またはローカル管理者）がデータベースバックアップまたはプロジェクトのバージョン管理データベースバックアップを実行します。個人的な環境では、その違いはそれほど明確ではないかもしれませんが、両方とも「データ保存」という「同じ」目的を提供するという考えを置くことは非常に明らかになります。プロジェクトでは、バージョン管理を使用して安定して反復可能なソフトウェア構成を取得し、バックアップを使用してシステムデータを安全に保ちます（偶発的または悪意のあるデータの削除、ハードドライブのクラッシュ、火災発生時のロールバックなどを防ぐため）。 ）。

分散（非中央化）バージョン管理を使用することは、より一般的なバックアップ方法を補完する効果的なバックアップ戦略です。 2つのアプローチを同時に使用する方法については、多くの言葉があります。

標準バックアップがどのように機能するかを見てみましょう。通常、みんなファイルシステムのファイルは、一部のリモートロケーションにコピーされます。これは通常、cronを使用して固定された定期的なスケジュールに従って行われます。これには増分バックアップオプションを含めることができます。つまり、一部のバックアップは、既存のバックアップとの違いのみを保存できます。これは通常、スペースを節約し、特定のスペースでより多くのバックアップを実行できるようにするために行われます。この場合、バックアップソフトウェアは選択したバックアップを再組み立てすることも実行します。

ここでは、重複排除バックアップソフトウェアについて特に言及します。ボグバックアップそしてレスティック。この最先端の増分バックアップ技術は、データを重複させることなく、新しいユニークなデータのみを保存しようとします。

利点：

1. 状態みんなファイルは特定の時点で保存されます。
2. 少なくとも完全に自動化されたバックアップでは、ユーザーに実際の作業は必要ありません。これは標準です。

欠点：

1. 保存された状態は特定のファイルとは関係ありません。これはランダムな時点です。
2. 実際、以前のバージョンのファイルは最終的に失われたり破棄されます。理論的には、すべてのバックアップの完全な履歴を保持することができますが、スペース上の理由からほとんど実行されません。しかし、重複排除バックアップソフトウェアの効率が向上し、データストレージのコストが低くなるにつれて、すべてのバックアップを保存することがより実現可能になりました。
3. 定期的にファイルシステムのスナップショットを保存する自動バックアップ戦略の本質的な制限のため、ある時点のファイルの状態は保存されません。より具体的には、関連ファイルシステムが破損した場合、最後のバックアップ以降のすべての変更は失われます。
4. 重要なバックアップソフトウェアに確認オプションがある場合でも、テスト/相互作用なしにバックアップが有効であるかどうかを知る方法はありません。これは圧縮バックアップの場合に特に問題です。

これで、分散バージョン管理（DVCS）を使用したバックアップと比較してみましょう。私が2015年初めにこの記事を書いた当時、GitとMercurialという2つの主要な無料の分散バージョン管理システムがありました。私は独自のバージョン管理ソフトウェアを使用することがいくつかの理由で悪い考えだと思うので、そのような獣の存在を無視します。もちろん、次のような他の分散バージョン制御システムも存在する。ビズル、ダルコス、単調なそして化石しかし、DVCSの分野では、MercurialとGitが最も一般的です。

バックアップにDVCSを使用する方法は？とても簡単です。リポジトリにコミットし、別の物理的な場所にあるリモートシステムにプッシュすることをお勧めします。ただし、接続されたUSBドライブを緊急に使用することもできます。

利点：

1. 各ファイルの保存状態は、定義に従って各ファイルに応じてカスタマイズおよび特定されます。
2. リポジトリは各ファイルの完全なスナップショット履歴を保持します。結局のところ、これはまさにバージョン管理に関するものです。
3. 適切なコミットがまだ準備されていないと仮定しても、非常に短い間隔で各ファイルのローカル状態を保存できます。これは、Mercurialで次の方法を使用して実行できます。 水銀キューの拡張または新しい進化的な拡張。これを行う方法の詳細については、この記事の範囲外ですが、効果的なワークフローは、後で永続コミットにマージ/整理/調整することができる非常にきめ細かい一時コミットです。子供は同様のキュー属性。私の知る限り。 GitはEvolveに似ていません。
4. リモートDVCSにプッシュすることは、リモートシステムのバックアップ/ストレージが正しく機能していることを確認する基本的な方法です。 100％保証ではありませんが（破損したリポジトリにプッシュ可能です）、少なくとも以前に実行した最新のコミットがまだリモートリポジトリに存在し、正しいハッシュなどを持っていることを伝えます。標準のDVCSは、リモートリポジトリの構造に問題があると大声で文句を言います。

欠点：

1. すべてのファイルが保存されるわけではなく、バージョン管理ファイルのみが保存されます。
2. バージョン管理を通じて特定のサイズ以上のファイルを保存することは、しばしば非現実的です。 Mercurialの場合、ファイルサイズは約10〜20 MB程度でパフォーマンスの問題が発生し始めます。以下を含む、この問題を解決しようとするいくつかの回避策/ヒントがあります。Mercurialの大容量ファイル拡張子有名な場所もあります。子添付、有名なJoey Hessが書いたが、私が知っている限り、これは適切なバックアップ戦略を置き換えることはできません。
3. ユーザーはリポジトリを設定し、コミットし、ログメッセージを作成し、一時コミットを永続コミットにマージして調整するために非常に懸命に働く必要があります。

「標準バックアップ」と「DVCSを使用したバックアップ」の長所と短所を意図的に反映しました。 DVCS Con 2を削除すると、正確な画像が生成されます。この記事の冒頭で述べたように、これらの戦略は相互補完的です。

私の意見では、賢明なユーザーはとにかくDVCSを使用する必要があるため、DVCS Con 3は実際にはConではありません。