インスタンスでのバックアップの構成

ディザスター リカバリー計画の一部として、自動バックアップを構成することで お使いの GitHub Enterprise Server インスタンスの運用データを保護できます。

この記事の内容

GitHub Enterprise Server Backup Utilitiesについて

GitHub Enterprise Server Backup Utilities は、独立したホストにインストールするバックアップ システムであり、セキュアな SSH ネットワーク接続経由で お使いの GitHub Enterprise Server インスタンスのバックアップ スナップショットを定期的に作成します。 スナップショットを使用して、既存の 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 を使うには、お使いの GitHub Enterprise Server インスタンス とは別のホスト システムが必要です。 システムの構成方法について詳しくは、github/backup-utils リポジトリの「要件」を参照してください。

GitHub Enterprise Server Backup Utilitiesは、重要なデータのための長期的な恒久ストレージの既存環境に統合することもできます。

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

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

ハードウェア推奨
vCPU 数4
メモリ8 GB
Storageプライマリインスタンスに割り当てられたストレージの5倍

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

詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「GitHub Enterprise Server Backup Utilities の要件」を参照してください。

GitHub Enterprise Server Backup Utilitiesのインストール

バックアップ ホストに GitHub Enterprise Server Backup Utilities をインストールするには、お使いのバージョンの GitHub Enterprise Server と互換性のある最新バージョンの GitHub Enterprise Server Backup Utilities を github/backup-utils リポジトリからダウンロードします。 たとえば、GitHub Enterprise Server のバージョン 3.8.4 を実行している場合は、3.10 シリーズの最新バージョンの GitHub Enterprise Server Backup Utilities をダウンロードします。 これは、GitHub Enterprise Server Backup Utilities のすべてのバージョンが 2 つのバージョンに下位互換性があるために可能です。つまり、GitHub Enterprise Server Backup Utilities 3.10 シリーズを使用して、バージョン 3.8、3.9、または 3.10 を実行している GitHub Enterprise Server インスタンスをバックアップおよび復元できます。

圧縮アーカイブをダウンロードした後、コンテンツを抽出してインストールできます。 詳細については、github/backup-utils リポジトリの概要を参照してください。

既存のバックアップ構成ファイルがある場合は、 backup.config新しく抽出してインストールしたバージョンの GitHub Enterprise Server Backup Utilities の所にファイルをコピーしてください。

GitHub Enterprise Server Backup Utilities によって作成されたバックアップ スナップショットは、ファイル内のデータ ディレクトリ変数によって設定されたGHE_DATA_DIRディスク パスbackup.configに書き込まれます。 スナップショットは、シンボリック リンクとハード リンクをサポートするファイル システムに格納する必要があります。

注: GitHub Enterprise Server Backup Utilities バージョンをアップグレードするときに誤ってデータ ディレクトリが上書きされないように、スナップショットが GitHub Enterprise Server Backup Utilities インストール ディレクトリのサブディレクトリに保持されないようにすることをお勧めします。

  1. github/backup-utils リポジトリのリリース ページから、関連する GitHub Enterprise Server Backup Utilities リリースをダウンロードします。

  2. tar を使用してリポジトリを抽出するには、次のコマンドを実行します。

    tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz

  3. ローカル リポジトリ ディレクトリに移動するには、次のコマンドを実行します。

    cd backup-utils

  4. インクルードされた backup.config-example ファイルを backup.config にコピーするには、次のコマンドを実行します。

    cp backup.config-example backup.config

  5. 構成をカスタマイズするには、テキスト エディターで backup.config を編集します。

    1. 以前に Git を使用して GitHub Enterprise Server Backup Utilities をアップグレードした場合は、既存の構成を新しいファイルに backup.config コピーしていることを確認します。 詳細については、「GitHub Enterprise Server Backup Utilities」を参照してください。

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

      注: お使いの GitHub Enterprise Server インスタンスがクラスターとして、またはロード バランサーを使用する高可用性構成に展開されている場合、お使いの GitHub Enterprise Server インスタンスへの SSH アクセス (ポート 122) が許可されている限り、GHE_HOSTNAME をロード バランサーのホスト名に指定できます。

      復旧されたインスタンスをすぐに利用できるようにするには、geo レプリケーション構成であっても、プライマリ インスタンスをターゲットにしてバックアップを実行します。

    3. GHE_DATA_DIR の値をバックアップ スナップショットを保存したいファイルシステムの場所に設定します。 バックアップ ホストと同じファイルシステム上の場所を選択することをお勧めします。

  6. バックアップ ホストにインスタンスへのアクセスを許可するには、プライマリ インスタンスの設定ページ http(s)://HOSTNAME/setup/settings を開き、承認された SSH キーの一覧にバックアップ ホストの SSH キーを追加します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

  7. バックアップ ホストで、ghe-host-check コマンドを使って、お使いの GitHub Enterprise Server インスタンスとの SSH 接続を確認します。

    ./bin/ghe-host-check

  8. 最初の完全バックアップを作成するには、次のコマンドを実行します。

    ./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 のインストールは、少なくとも お使いの GitHub Enterprise Server インスタンス と同じバージョンである必要があり、3 つ以上先のバージョンにインストールすることはできません。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの「GitHub Enterprise Server バージョン要件」を参照してください。

  1. GitHub Enterprise Server Backup Utilities のインストール方法を確認します。 以前のバージョンの GitHub Enterprise Server Backup Utilities では、ローカル Git リポジトリでのインストールと更新がサポートされましたが、この方法はサポートされなくなりました。

    1. バックアップ ホストで、GitHub Enterprise Server Backup Utilities ディレクトリ (通常は backup-utils) に移動します。

    2. 有効な作業ディレクトリが Git リポジトリ内に存在するかどうかを確認するには、次のコマンドを実行します。

      git rev-parse --is-inside-work-tree

  2. GitHub Enterprise Server Backup Utilities をアップグレードする方法を確認するには、次の出力を git rev-parse --is-inside-work-tree確認します。

    • 出力が true の場合、GitHub Enterprise Server Backup Utilities は、プロジェクトの Git リポジトリを複製することによってインストールされました。 アップグレードするには、既存のbackup.config構成をコピーし、「GitHub Enterprise Server Backup Utilities のインストール」の手順に従います。
    • 出力に fatal: not a git repository (or any of the parent directories) が含まれている場合、GitHub Enterprise Server Backup Utilitiesを圧縮アーカイブ ファイルから抽出します。 アップグレードするには、「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 Server インスタンス を復元できます。 インスタンスを復元する前に、バックアップホストの SSH キーをターゲットの GitHub Enterprise インスタンスに認証済み SSH キーとして追加する必要があります。

お使いの GitHub Enterprise Server インスタンス へのバックアップ復元を実行するとき、データを復元できる過去の機能リリースは最大 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 にアップグレードする必要があります。

ネットワークの設定はバックアップ スナップショットから除外されます。 復元の後、ターゲットの GitHub Enterprise Server インスタンスで手動でネットワークを構成する必要があります。

前提条件

  1. プライマリ インスタンスでメンテナンス モードが有効になっていて、すべてのアクティブなプロセスが完了していることを確認します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
  2. 高可用性構成のすべてのレプリカ ノードでレプリケーションを停止します。 詳しくは、「High Availability設定について」を参照してください。
  3. バックアップ復元のターゲットとして使用するために、新しい GitHub Enterprise Server インスタンスをプロビジョニングする。 詳しくは、「GitHub Enterprise Server インスタンスをセットアップする」を参照してください。
  4. お使いの GitHub Enterprise Server インスタンス で GitHub Actions が有効になっている場合は、交換用インスタンスで GitHub Actions 用の外部ストレージ プロバイダーを構成する必要があります。 詳しくは、「GitHub Actions を有効化して GitHub Enterprise Server をバックアップおよび復元する」を参照してください。

復元操作の開始

最後に成功したスナップショットを使ってバックアップ ホストから お使いの GitHub Enterprise Server インスタンス を復元するには、ghe-restore コマンドを使います。 ghe-restore では、次の追加オプションを使用できます。

  • -c フラグは、既に設定されている場合でも、ターゲット ホストで設定、証明書、およびライセンス データを上書きします。 テストのためにステージングインスタンスを設定しており、ターゲット上の依存の設定を残しておきたい場合には、このフラグを省いてください。 詳しくは、github/backup-utils リポジトリにある GitHub Enterprise Server Backup Utilities README の "バックアップと復元コマンドの使用" に関するセクションをご覧ください。
  • -s フラグにより、異なるバックアップ スナップショットを選択できます。

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.

必要に応じて復元を検証するには、指定した IP アドレスのリストへのアクセスを許可するように IP 例外リストを構成します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

高可用性構成のインスタンスでは、既存または空のインスタンスの新しいディスクに復元した後で、ghe-repl-status により、サーバーの UUID が古いために Git または Alambic のレプリケーションが同期されていないことが報告される場合があります。 これらの古い UUID は、高可用性構成の廃止されたノードがアプリケーション データベースにはまだ存在しているのに、復元されたレプリケーション構成には存在しないことによる結果である可能性があります。

復元が完了した後、レプリケーションを始める前に修復するには、ghe-repl-teardown を使って古い UUID を破棄できます。 さらにサポートが必要な場合は、GitHub Enterprise サポート にアクセスしてください。

バックアップまたは復元の進行状況の監視

バックアップまたは復元の操作中に、バックアップ ホストで ghe-backup-progress ユーティリティを使って、操作の進行状況を監視できます。 このユーティリティは、各ジョブの進行状況を順番に出力します。

バックアップ ホストで進行状況を監視するには、GitHub Enterprise Server Backup Utilities が格納されているディレクトリから、次のコマンドを実行します。

Shell
bin/ghe-backup-progress

既定では、このユーティリティは操作が完了するまで進行状況を継続的に出力します。 任意のキーを押して、プロンプトに戻ることができます。

必要に応じて、次のコマンドを実行し、現在の進行状況と最後に完了したジョブを出力して、すぐに終了することができます。

Shell
bin/ghe-backup-progress --once