GitHub Enterprise Server Backup Utilitiesについて
GitHub Enterprise Server Backup Utilities は、個別のホストにインストールするバックアップ システ� で、 のバックアップ スナップショットをセキュアな SSH ネットワーク接続経由で定期的に取得します。 スナップショットを使用して、既存の GitHub Enterprise Server インスタンスをバックアップホストから以前の状態に復元できます。
ネットワーク経由で転送されるのは最後のスナップショット以降に追� されたデータのみで、追� の物理ストレージ� �域もその分� けしか� めません。 パフォーマンスへの影響を最小化するために、バックアップは最低のCPU/IO優先度の下でオンライン実行されます。 バックアップを行うために、メンテナンスウィンドウをスケジューリングする必要はありません。
GitHub Enterprise Server Backup Utilities のメジャー リリースとバージョン番号は、GitHub Enterprise Server の機能リリースと一致します。 両方の製品の最新バージョン 4 つをサポートしています。 詳しい情� �については、「GitHub Enterprise Server のリリース」をご覧く� さい。
機能、要件、および高度な使用方法について詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの GitHub Enterprise Server Backup Utilities README を参照してく� さい。
前提条件
GitHub Enterprise Server Backup Utilities を利用するには、 とは別の Linux もしくは Unix ホスト システ� が必要です。
GitHub Enterprise Server Backup Utilitiesは、重要なデータのための長期的な恒久ストレージの既存環境に統合することもできます。
バックアップ ホストと は、地理的に離れたところに配置することをおすすめします。 そうすることで、プライマリのサイトにおける大規模な災害やネットワーク障害に際してもリカバリにバックアップが利用できることが保証されます。
物理的なストレージの要求は、Gitリポジトリのディスク利用状況と予想される成長パターンによって異なります。
ハードウェア | 推奨 |
---|---|
vCPU 数 | 2 |
[メモリ] | 2 GB |
Storage | プライマリインスタンスに割り当てられたストレージの5倍 |
ユーザのアクティビティや他の製品との結合といった利用方法によっては、さらに多くのリソースが必要になることがあります。
詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「GitHub Enterprise Server Backup Utilities の要件」を参照してく� さい。
GitHub Enterprise Server Backup Utilitiesのインストール
バックアップ ホストに GitHub Enterprise Server Backup Utilities をインストールするには、プロジェクトの Git リポジトリを複製することをお勧めします。 この方法では、Git を使用して新しいリリースを直接フェッチすることができ、新しいバージョンをインストールするときに既存のバックアップ構成ファイル backup.config
が保持されます。
または、ホスト マシンがインターネットにアクセスできない� �合は、圧縮アーカイブとして各 GitHub Enterprise Server Backup Utilities リリースをダウンロードし、コンテンツを抽出してインストールできます。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「概要」を参照してく� さい。
バックアップ スナップショットは、backup.config
ファイル内のGHE_DATA_DIR
データ ディレクトリ変数によって設定されたディスク パスに書き込まれます。 スナップショットは、シンボリック リンクとハード リンクをサポートするファイル システ� に� �納する必要があります。
注: GitHub Enterprise Server Backup Utilities バージョンをアップグレードするときに誤ってデータ ディレクトリが上書きされないように、スナップショットが GitHub Enterprise Server Backup Utilities インストール ディレクトリのサブディレクトリに保持されないようにすることをお勧めします。
-
GitHub Enterprise Server Backup Utilities プロジェクト リポジトリをバックアップ ホスト上のローカル ディレクトリに複製するには、次のコマンドを実行します。
$ git clone https://github.com/github/backup-utils.git /path/to/target/directory/backup-utils
-
ローカル リポジトリ ディレクトリに移動するには、次のコマンドを実行します。
cd backup-utils
-
最新のプロジェクト リリース バージョンに更新するには、
git checkout stable
コマンドを実行してstable
ブランチを使用します。git checkout stable
または、特定のプロジェクト バージョンを使用するには、次のコマンドを実行し、
X.Y.Z
を目的のリリース バージョンに置き換えます。$ git checkout vX.Y.Z
-
インクルードされた
backup.config-example
ファイルをbackup.config
にコピーするには、次のコマンドを実行します。cp backup.config-example backup.config
-
構成をカスタマイズするには、テキスト エディターで
backup.config
を編集します。-
GHE_HOSTNAME
の値をプライマリの GitHub Enterprise Server インスタンスのホスト名あるいは IP アドレスに設定します。注: がクラスターとして、またはロード バランサーを使用する高可用性構成に展開されている� �合は、 への SSH アクセス (ポート 122 上) が許可されている限り、
GHE_HOSTNAME
をロード バランサーのホスト名に指定できます。復旧されたアプライアンスがすぐに利用できることを保証するために、geo レプリケーション構成の� �合であってもプライマリ インスタンスをターゲットとしたバックアップを実行してく� さい。
-
GHE_DATA_DIR
の値をバックアップ スナップショットを保存したいファイルシステ� の� �所に設定します。 手� � 1 で Git リポジトリを複製した� �所以外の、バックアップ ホストと同じファイル システ� 上の� �所を選ぶことをお勧めします。
-
-
バックアップ ホストにインスタンスへのアクセスを許可するには、プライマリ インスタンスの設定ページ
http(s)://HOSTNAME/setup/settings
を開き、承認された SSH キーの一覧にバックアップ ホストの SSH キーを追� します。 詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。 -
バックアップ ホストで、
ghe-host-check
コマンドを使用して、 との SSH 接続を確認します。./bin/ghe-host-check
-
最初の完全バックアップを作成するには、次のコマンドを実行します。
./bin/ghe-backup
高度な使用方法について詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの GitHub Enterprise Server Backup Utilities README を参照してく� さい。
GitHub Enterprise Server Backup Utilities のアップグレード
GitHub Enterprise Server Backup Utilities をアップグレードするときは、現在のバージョンの GitHub Enterprise Server で動作するリリースを選ぶ必要があります。 GitHub Enterprise Server Backup Utilities のインストールは、少なくとも と同じバージョンである必要があり、3 つ以上先のバージョンにインストールすることはできません。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「GitHub Enterprise Server バージョン要件」を参照してく� さい。 最新の変更をフェッチしてチェックアウトすることで、Git リポジトリの GitHub Enterprise Server Backup Utilities をアップグレードできます。
または、インストールに Git リポジトリを使用しない� �合は、新しいアーカイブを抽出することも、代わりに Git リポジトリを使用するように方法を変更することもできます。
インストールの種類の確認
GitHub Enterprise Server Backup Utilities のインストール方法を確認し、インストールをアップグレードする最適な方法を決定できます。
-
バックアップ ホストで、GitHub Enterprise Server Backup Utilities ディレクトリ (通常は
backup-utils
) に移動します。 -
有効な作業ディレクトリが Git リポジトリ内に存在するかどうかを確認するには、次のコマンドを実行します。
git rev-parse --is-inside-work-tree
出力が
true
の� �合、GitHub Enterprise Server Backup Utilities は、プロジェクトの Git リポジトリを複製することによってインストールされました。 出力にfatal: not a git repository (or any of the parent directories)
が含まれている� �合、GitHub Enterprise Server Backup Utilities は、圧縮アーカイブ ファイルを抽出することによってインストールされたと考えられます。 インストールが Git リポジトリにある� �合は、Git を使用して最新バージョンをインストールできます。 インストールが圧縮アーカイブ ファイルから行われた� �合は、最新バージョンをダウンロードして抽出するか、Git を使用して GitHub Enterprise Server Backup Utilities を再インストールして、将来のアップグレードを簡略化できます。
Git リポジトリでのインストールのアップグレード
-
バックアップ ホストで、GitHub Enterprise Server Backup Utilities ディレクトリ (通常は
backup-utils
) に移動します。注: GitHub Enterprise Server Backup Utilities をアップグレードする前に、既存の
backup.config
ファイルのコピーを$HOME/backup.config
のような一時的な� �所に作成することをお勧めします。 -
git fetch
コマンドを実行して、最新のプロジェクト更新プログラ� をダウンロードします。git fetch
-
最新のプロジェクト リリース バージョンに更新するには、
git checkout stable
コマンドを実行してstable
ブランチを使用します。git checkout stable
または、特定のプロジェクト バージョンを使用するには、次のコマンドを実行し、
X.Y.Z
を目的のリリース バージョンに置き換えます。
1. 正常にアップグレードされたことを確認するには、次のコマンドを実行します。$ git checkout vX.Y.Z
./bin/ghe-backup --version
-
構成済みの GitHub Enterprise Server 間の SSH 接続を確認するには、次のコマンドを実行します。
./bin/ghe-host-check
圧縮アーカイブの代わりに Git を使用してアーカイブする
バックアップ ホストにインターネット接続があり、以前に圧縮アーカイブ (.tar.gz
) を使用して GitHub Enterprise Server Backup Utilities をインストールまたはアップグレードした� �合は、代わりにインストールに Git リポジトリを使用することをお勧めします。 Git を使用してアップグレードすると、作業が少なくなり、バックアップ構成が保持されます。
-
バックアップ ホストで、GitHub Enterprise Server Backup Utilities ディレクトリ (通常は
backup-utils
) に移動します。 -
既存の GitHub Enterprise Server Backup Utilities の構成をバックアップするには、現在の
backup.config
ファイルをホー� ディレクトリなどの安全な� �所にコピーします。$ cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
-
GitHub Enterprise Server Backup Utilities Git リポジトリをインストールするバックアップ ホスト上のローカル ディレクトリに移動します。
-
プロジェクト リポジトリをバックアップ ホスト上のディレクトリに複製するには、次のコマンドを実行します。
git clone https://github.com/github/backup-utils.git
-
複製されたリポジトリに移動するには、次のコマンドを実行します。
cd backup-utils
-
最新のプロジェクト リリース バージョンに更新するには、
git checkout stable
コマンドを実行してstable
ブランチを使用します。git checkout stable
または、特定のプロジェクト バージョンを使用するには、次のコマンドを実行し、
X.Y.Z
を目的のリリース バージョンに置き換えます。$ git checkout vX.Y.Z
-
前の手� �からバックアップ構成を復元するには、既存のバックアップ構成ファイルをローカル リポジトリ ディレクトリにコピーします。 コマンドのパスを、手� � 2 で保存したファイルの� �所に置き換えます。
$ cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
注: 複製後にバックアップ構成ファイルを復元する� �所を選ぶことができます。 構成ファイルを配置できる� �所について詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「概要」を参照してく� さい。
-
バックアップ構成ファイル内のディレクトリまたはスクリプトのパスが正しいことを確認するには、テキスト エディターでファイルを確認します。
-
正常にアップグレードされたことを確認するには、次のコマンドを実行します。
./bin/ghe-backup --version
-
構成済みの GitHub Enterprise Server 間の SSH 接続を確認するには、次のコマンドを実行します。
./bin/ghe-host-check
-
手� � 1 から古い GitHub Enterprise Server Backup Utilities ディレクトリ (圧縮アーカイブのインストール� �所) を削除します。
バックアップのスケジューリング
cron(8)
コマンドや同様のコマンド スケジューリング サービスを使用して、バックアップ ホストで定期的なバックアップをスケジュール設定できます。 設定されたバックアップ� �度によって、リカバリー計画での最悪の目標復旧ポイント (RPO) が決まります。 たとえば、毎日午前 0 時にバックアップを実行するようにスケジュール設定した� �合、災害のシナリオで最大 24 時間分のデータが失われる可能性があります。 プライマリサイトのデータが� �壊された� �合に、最悪でも最大 1 時間分のデータ損失で収まることが保証されるように、1 時間ごとのバックアップスケジュールから始めることをおすすめします。
バックアップの試行が重複すると、ghe-backup
コマンドはエラー メッセージを表示して中断し、同時バックアップが存在することを示します。 そのような� �合は、スケジュール設定したバックアップの� �度を減らすことをおすすめします。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの GitHub Enterprise Server Backup Utilities README を参照してく� さい。
バックアップの復元
プライマリ サイトで長時間の停止または壊滅的なイベントが発生した� �合は、別の GitHub Enterprise アプライアンスをプロビジョニングしてバックアップ ホストから復元することで、 を復元できます。 アプライアンスを復元する前に、バックアップホストの SSH キーをターゲットの GitHub Enterprise アプライアンスに認証済み SSH キーとして追� する必要があります。
注意: へのバックアップを復元する� �合は、同じバージョンのサポート ルールが適用されます。 最大 2 つ前の機能リリースからしかデータを復元できません。
たとえば、GitHub Enterprise Server 3.0.x からバックアップを取得した� �合、バックアップを GitHub Enterprise Server 3.2.x インスタンスに復元できます。 GitHub Enterprise Server 2.22.x のバックアップから 3.2.x を実行しているインスタンスにデータを復元することはできません。これは、バージョンを 3 回ジャンプするためです (2.22 から 3.0、3.1、3.2 の� �)。 最初に 3.1.x を実行しているインスタンスに復元してから、3.2.x にアップグレードする必要があります。
最後に成功したスナップショットから を復元するには、ghe-restore
コマンドを使用します。
注: バックアップを復元する前に、次のことを確認してく� さい。
- プライマリ インスタンスでメンテナンス モードが有効になり、すべてのアクティブなプロセスが完了している。 詳細については、「メンテナンス モードの有効化」を参照してく� さい。
- 高可用性構成のすべてのレプリカでレプリケーションが停止している。 詳しくは、「高可用性構成について」の
ghe-repl-stop
コマンドを参照してく� さい。 - で GitHub Actions が有効になっている� �合は、まず交換用アプライアンスで GitHub Actions 外部ストレージ プロバイダーを構成する必要があります。 詳細については、「GitHub Actions を有効にして、GitHub Enterprise Server をバックアップおよび復元する」を参照してく� さい。
ghe-restore
コマンドを実行すると、次のような出力が表示されます。
$ ghe-restore -c 169.154.1.1
> Checking for leaked keys in the backup snapshot that is being restored ...
> * No leaked keys found
> Connect 169.154.1.1:122 OK (v2.9.0)
> WARNING: All data on GitHub Enterprise appliance 169.154.1.1 (v2.9.0)
> will be overwritten with data from snapshot 20170329T150710.
> Please verify that this is the correct restore host before continuing.
> Type 'yes' to continue: yes
> Starting restore of 169.154.1.1:122 from snapshot 20170329T150710
# ...output truncated
> Completed restore of 169.154.1.1:122 from snapshot 20170329T150710
> Visit https://169.154.1.1/setup/settings to review appliance configuration.
注意: ネットワーク設定はバックアップ スナップショットから除外されます。 ご使用の環境に合わせて、ターゲットの GitHub Enterprise Server アプライアンスでネットワークを手動で設定する必要があります。
ghe-restore
コマンドでは、次の追� オプションを使用できます。
-c
フラグは、既に設定されている� �合でも、ターゲット ホストで設定、証明書、およびライセンス データを上書きします。 テストのためにステージングインスタンスを設定しており、ターゲット上の依存の設定を残しておきたい� �合には、このフラグを省いてく� さい。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの GitHub Enterprise Server Backup Utilities README の「バックアップと復旧コマンドの使用」セクションを参照してく� さい。-s
フラグにより、異なるバックアップ スナップショットを選択できます。