このスレッドは、git reposのバックアップを実行する方法についての洞察を得るために非常に役立ちました。自分にとって「正しい方法」（tm）を見つけるためのヒント、情報、または結論がまだ欠けていると思います。したがって、他の人を助けるためにここで私の考えを共有し、それらを強化するための議論にそれらを置きます。ありがとう。
したがって、元の質問をピックアップすることから始めます。
- 目標は、gitリポジトリの「完全」バックアップにできる限り近づけることです。
次に、典型的な願望でそれを豊かにし、いくつかの事前設定を指定します。
- サービスのダウンタイムを回避するために、「ホットコピー」によるバックアップが推奨されます。
- gitの欠点は、追加のコマンドによって回避されます。
- スクリプトはバックアップを実行して、1つのバックアップの複数のステップを組み合わせ、人的ミス（タイプミスなど）を回避する必要があります。
- さらに、スクリプトはリストアを実行して、ダンプをターゲットマシンに適合させる必要があります。たとえば、元のマシンの構成でさえ、バックアップ後に変更されている可能性があります。
- 環境は、ハードリンクをサポートするファイルシステムを備えたLinuxマシン上のgitサーバーです。
1. "フル" git repoバックアップとは何ですか？
「100％」バックアップとは見方が異なります。ここに2つの典型的なものがあります。
＃1開発者の視点
gitのは、開発者向けツールであるとを経由してこの観点をサポートgit clone --mirrorしてgit bundle --all。
＃2管理者の視点
- コンテンツファイル
- 特殊なケース「packfile」：gitはガベージコレクション中にオブジェクトを結合してパックファイルに圧縮します（を参照
git gc）
- gitの設定
- オプション：OS構成（ファイルシステムのアクセス許可など）
gitは開発者ツールであり、管理者に任せます。git構成とOS構成のバックアップは、コンテンツのバックアップから分離されていると見なす必要があります。
2.テクニック
- 「コールドコピー」
- サービスを停止して、ファイルに排他的にアクセスします。ダウンタイム！
- 「ホットコピー」
- サービスは、バックアップの目的で固定状態を提供します。進行中の変更はその状態に影響を与えません。
3.考慮すべきその他のトピック
それらのほとんどはバックアップ用の汎用です。
- 完全バックアップを保持するのに十分なスペースがありますか？何世代が保存されますか？
- 漸進的なアプローチが必要ですか？何世代が保存され、いつ完全バックアップを再度作成するのですか？
- バックアップが作成後または時間の経過とともに破損していないことを確認するにはどうすればよいですか？
- ファイルシステムはハードリンクをサポートしていますか？
- バックアップを単一のアーカイブファイルに入れるか、ディレクトリ構造を使用しますか？
4. gitがコンテンツをバックアップするために提供するもの
git gc --auto
- docs：man git-gc
- リポジトリをクリーンアップして圧縮します。
git bundle --all
- docs：man git-bundle、man git-rev-list
- Atomic = "ホットコピー"
- バンドルはダンプファイルであり、gitで直接使用できます（検証、複製など）。
- 増分抽出をサポートします。
- 経由で検証可能
git bundle verify。
git clone --mirror
- docs：man git-clone、man git-fsck、git clone --mirrorとgit clone --bareの違いは何ですか
- Atomic = "ホットコピー"
- ミラーは本当のgitリポジトリです。
- このコマンドの主な目的は、元のリポジトリから定期的に更新をフェッチする完全なアクティブミラーを構築することです。
- スペースの浪費を避けるために、同じファイルシステム上のミラーのハードリンクをサポートします。
- 経由で検証可能
git fsck。
- ミラーは、完全なファイルバックアップスクリプトの基礎として使用できます。
5.コールドコピー
コールドコピーバックアップでは、常にフルファイルバックアップを実行できます。gitreposへのすべてのアクセスを拒否し、バックアップを実行して、再度アクセスを許可します。
- 考えられる問題
- ファイルシステムを介した共有アクセスなど、すべてのアクセスを拒否するのは簡単ではないかもしれません。
- リポジトリが単一ユーザーのクライアント専用マシンにある場合でも、自動バックアップの実行中にユーザーが何かをコミットする可能性があります:(
- サーバーでのダウンタイムは許容できない場合があり、複数の巨大なリポジトリのバックアップを実行すると、時間がかかる場合があります。
- 緩和策のアイデア：
- 一般的に、クライアントが同じマシン上にある場合でも、ファイルシステムを介した直接リポジトリへのアクセスを防止します。
- SSH / HTTPアクセスの場合は、git承認マネージャー（gitoliteなど）を使用して、スクリプトで動的にアクセスを管理したり、認証ファイルを変更したりします。
- リポジトリを1つずつバックアップして、各リポジトリのダウンタイムを削減します。1つのリポジトリを拒否し、バックアップを実行して再度アクセスを許可してから、次のリポジトリを続行します。
- 開発者の混乱を避けるために計画された保守スケジュールを持っています。
- リポジトリが変更された場合のみバックアップします。実装が非常に難しいかもしれません。たとえば、オブジェクトのリストとパックファイルを念頭に置いて、設定とフックのチェックサムなどです。
6.ホットコピー
進行中のコミットによってデータが破損するリスクがあるため、アクティブなリポジトリではファイルバックアップを実行できません。ホットコピーは、アクティブなリポジトリの固定状態をバックアップの目的で提供します。進行中のコミットはそのコピーに影響を与えません。上記のように、gitのクローンおよびバンドル機能はこれをサポートしますが、「100％管理」バックアップの場合、追加のコマンドを使用していくつかのことを行う必要があります。
「100％管理者」ホットコピーバックアップ
- オプション1：
git bundle --allコンテンツのフル/インクリメンタルダンプファイルを作成し、構成ファイルを個別にコピー/バックアップするために使用します。
- オプション2：
git clone --mirror構成を個別に使用、処理、コピーしてから、ミラーのフルファイルバックアップを実行します。
- ノート：
- ミラーは新しいリポジトリであり、作成時に現在のgitテンプレートが読み込まれます。
- 構成ファイルとディレクトリをクリーンアップしてから、元のソースリポジトリから構成ファイルをコピーします。
- バックアップスクリプトは、ミラーのファイル権限などのOS構成も適用する場合があります。
- ハードリンクをサポートするファイルシステムを使用し、ソースリポジトリと同じファイルシステム上にミラーを作成して、速度を上げ、バックアップ中のスペース消費を減らします。
7.復元
- ターゲットマシンのgit設定と最新の「実行方法」の考え方を確認して採用します。
- ターゲットマシンのOS構成と最新の「実行方法」の考え方を確認して採用します。