アプライアンスでのバックアップの設定

システム災害復旧計画の一部として、自動化バックアップを設定してGitHub Enterprise Serverのインスタンスのプロダクションデータを保護できます。

GitHub Enterprise Serverバックアップユーティリティについて

GitHub Enterprise Serverバックアップユーティリティは、個別のホストにインストールするバックアップシステムで、GitHub Enterprise ServerのインスタンスのバックアップスナップショットをセキュアなSSHネットワーク接続経由で定期的に取得します。 スナップショットを使用して、既存の GitHub Enterprise Server インスタンスをバックアップホストから以前の状態に復元できます。

ネットワーク経由で転送されるのは最後のスナップショット以降に追加されたデータのみで、追加の物理ストレージ領域もその分だけしか占めません。 パフォーマンスへの影響を最小化するために、バックアップは最低のCPU/IO優先度の下でオンライン実行されます。 バックアップを行うために、メンテナンスウィンドウをスケジューリングする必要はありません。

機能、要求事項、高度な利用方法に関する詳しい情報についてはGitHub Enterprise ServerバックアップユーティリティREADMEを参照してください。

必要な環境

GitHub Enterprise Serverバックアップユーティリティを利用するには、GitHub Enterprise Serverのインスタンスとは別のLinuxもしくはUnixホストシステムが必要です。

GitHub Enterprise Serverバックアップユーティリティは、重要なデータのための長期的な恒久ストレージの既存環境に統合することもできます。

バックアップホストとGitHub Enterprise Serverのインスタンスは、地理的に離れたところに配置することをおすすめします。 そうすることで、プライマリのサイトにおける大規模な災害やネットワーク障害に際してもリカバリにバックアップが利用できることが保証されます。

物理的なストレージの要求は、Gitリポジトリのディスク利用状況と予想される成長パターンによって異なります。

ハードウェア推奨構成
vCPUs2
メモリ2 GB
ストレージプライマリインスタンスに割り当てられたストレージの5倍

ユーザのアクティビティや他の製品との結合といった利用方法によっては、さらに多くのリソースが必要になることがあります。

GitHub Enterprise Serverバックアップユーティリティのインストール

注意: リカバリされたアプライアンスがすぐに利用できることを保証するために、Geo-replication構成の場合であってもプライマリインスタンスをターゲットとしたバックアップを実行してください。

  1. 最新のGitHub Enterprise Serverバックアップユーティリティリリースをダウンロードし、tarコマンドで展開してください。

    $ tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz     
  2. 含まれている backup.config-example ファイルを backup.config にコピーして、エディタで開きます。

  3. GHE_HOSTNAME の値をプライマリの GitHub Enterprise Server インスタンスのホスト名あるいは IP アドレスに設定します。

    Note: If your GitHub Enterprise Serverのインスタンス is deployed as a cluster or in a high availability configuration using a load balancer, the GHE_HOSTNAME can be the load balancer hostname, as long as it allows SSH access (on port 122) to GitHub Enterprise Serverのインスタンス.

  4. GHE_DATA_DIR の値をバックアップスナップショットを保存したいファイルシステムの場所に設定します。

  5. https://HOSTNAME/setup/settings にあるプライマリインスタンスの設定ページを開き、バックアップホストの SSH キーを認証済みの SSH キーのリストに追加します。 詳しい情報については、「管理シェル (SSH) にアクセスする」を参照してください。

  6. ghe-host-check コマンドで、GitHub Enterprise Serverのインスタンス との SSH 接続を確認します。

    $ bin/ghe-host-check        
  7. 最初のフルバックアップを作成するには、ghe-backup コマンドを実行します。

    $ bin/ghe-backup        

高度な使い方に関する詳しい情報については、GitHub Enterprise Serverバックアップユーティリティ READMEを参照してください。

バックアップのスケジューリング

バックアップのスケジュールを設定する cron(8) コマンドや同様のコマンドスケジューリングサービスを使用すれば、バックアップホストで定期的なバックアップをスケジュール設定できます。 設定されたバックアップ頻度によって、リカバリー計画での最悪の目標復旧ポイント (RPO) が決まります。 たとえば、毎日午前 0 時にバックアップを実行するようにスケジュール設定した場合、災害のシナリオで最大 24 時間分のデータが失われる可能性があります。 プライマリサイトのデータが破壊された場合に、最悪でも最大 1 時間分のデータ損失で収まることが保証されるように、1 時間ごとのバックアップスケジュールから始めることをおすすめします。

バックアップの試行が重複すると、ghe-backup コマンドはエラーメッセージを表示して中断し、同時バックアップが存在することを示します。 そのような場合は、スケジュール設定したバックアップの頻度を減らすことをおすすめします。 詳しい情報については、GitHub Enterprise Serverバックアップユーティリティ README の「スケジューリングバックアップ」を参照してください。

バックアップのリストア

万が一、プライマリサイトで長時間の停止または壊滅的なイベントが発生した場合は、別の GitHub Enterprise アプライアンスをプロビジョニングしてバックアップホストから復元を実行することで、GitHub Enterprise Serverのインスタンス を復元できます。 アプライアンスを復元する前に、バックアップホストの SSH キーをターゲットの GitHub Enterprise アプライアンスに認証済み SSH キーとして追加する必要があります。

注釈: GitHub Enterprise Serverのインスタンス で GitHub Actions が有効になっている場合は、ghe-restore コマンドを実行する前に、まず交換用アプライアンスで GitHub Actions 外部ストレージプロバイダを設定する必要があります。 詳しい情報については、「GitHub Actions を有効にして GitHub Enterprise Server をバックアップおよび復元する」を参照してください。

Note: When performing backup restores to GitHub Enterprise Serverのインスタンス, the same version supportability rules apply. You can only restore data from at most two feature releases behind.

For example, if you take a backup from GHES 3.0.x, you can restore it into a GHES 3.2.x instance. But, you cannot restore data from a backup of GHES 2.22.x onto 3.2.x, because that would be three jumps between versions (2.22 > 3.0 > 3.1 > 3.2). You would first need to restore onto a 3.1.x instance, and then upgrade to 3.2.x.

最後に成功したスナップショットから 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バックアップユーティリティREADMEの"バックアップ及びリストアコマンドの利用"セクションを参照してください。
  • -s フラグにより、異なるバックアップスナップショットを選択できます。

このドキュメントは役立ちましたか?

プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?