大規模リファレンスアーキテクチャのバックアップとリストア

このドキュメントでは、以下の方法について説明します：

このドキュメントは、以下の環境を対象としています：

日次バックアップの設定

PostgreSQLとオブジェクトストレージデータのバックアップ設定

backupコマンドは pg_dump 、100GBを超えるデータベースには適していません。ネイティブで堅牢なバックアップ機能を持つPostgreSQLソリューションを選択する必要があります。

ブロブや コンテナ・レジストリなどのGitLabデータの保存には、オブジェクトストレージ（NFSではない）を推奨します。

  1. RDSとS3の両方のデータをバックアップするためにAWS Backupを設定します。最大限の保護のために、スナップショットバックアップだけでなく、継続的なバックアップも設定します。
  2. バックアップを別のリージョンにコピーするように AWS Backup を設定します。AWSがバックアップを取ると、バックアップはバックアップが保存されているリージョンでのみリストアできます。
  3. AWS Backupが少なくとも1回のスケジュールバックアップを実行した後、必要に応じてオンデマンドバックアップを作成できます。

Git リポジトリのバックアップ設定

note
Gitalyからオブジェクトストレージに直接リポジトリをバックアップする機能を追加する機能が提案されています。エピック10077を参照ください。

Gitリポジトリをバックアップします：

  1. GitLab Railsノードに、GitリポジトリとGitリポジトリのアーカイブを保存するのに十分なストレージが接続されていることを確認してください。さらに、フォークされたリポジトリの内容は、バックアップ中にそのフォークに複製されます。例えば、5GB分のGitリポジトリと1GBのリポジトリのフォークが2つある場合、最低でも14GBのアタッチストレージが必要です：
    • 7 GB の Git データ。
    • Gitの全データの7GBのアーカイブファイル。
  2. GitLab RailsノードにSSH接続します。
  3. バックアップをリモートのクラウドストレージにアップロードする設定。
  4. このバケットに対してAWS Backupを設定するか、本番用データオブジェクトストレージのバケットと同じアカウントとリージョンのバケットを使用し、このバケットが既存のAWS Backupに含まれていることを確認します。

  5. PostgreSQL データをスキップしてバックアップコマンドを実行します：

    sudo gitlab-backup create SKIP=db

    結果のtarファイルには、Gitリポジトリと一部のメタデータだけが含まれます。アップロード、アーティファクト、LFSなどのブロブは明示的にスキップする必要はありません。このコマンドはデフォルトではオブジェクトストレージをバックアップしないからです。tarファイルは、/var/opt/gitlab/backups ディレクトリ とに作成され、ファイル名は_gitlab_backup.tarで終わります。

    リモートのクラウドストレージにバックアップをアップロードする設定にしているため、tarファイルはリモートリージョンにアップロードされ、ディスクから削除されます。

  6. 次のステップのために、バックアップファイルのタイムスタンプに注意してください。たとえば、バックアップ名が1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar の場合、タイムスタンプは1493107454_2018_04_25_10.6.4-ce です。

  7. backup コマンドをもう一度実行し、今度はGit リポジトリの増分バックアップとバックアップ元のファイルのタイムスタンプを指定します。前のステップのタイムスタンプの例を使うと、コマンドは次のようになります：

    sudo gitlab-backup create SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1493107454_2018_04_25_10.6.4-ce
  8. 増分バックアップが成功し、オブジェクトストレージにアップロードされたことを確認します。

  9. 毎日バックアップを行うようにcronを設定します。root ユーザーのcrontabを編集します：

    sudo su -
crontab -e

  10. そこに以下の行を追加して、毎日午前2時にバックアップをスケジュールします：

    0 2 * * * /opt/gitlab/bin/gitlab-backup create SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1493107454_2018_04_25_10.6.4-ce CRON=1

設定ファイルのバックアップの設定

設定とシークレットがデプロイの外部で定義され、デプロイされる場合、バックアップ戦略の実装は特定の設定と要件に依存します。一例として、複数のリージョンにレプリケーションしてシークレットをAWS Secret Managerに保存し、シークレットを自動的にバックアップするスクリプトを設定することができます。

設定とシークレットがデプロイ内部でのみ定義されている場合：

  1. 設定ファイルの格納]では、設定ファイルとシークレットファイルを抽出する方法について説明します。
  2. これらのファイルは、より制限の厳しい別のオブジェクトストレージアカウントにアップロードする必要があります。

バックアップのリストア

GitLabインスタンスのバックアップをリストアします。

前提条件

バックアップを復元する前に

  1. 作業先のGitLabインスタンスを選択します。
  2. デスティネーションのGitLabインスタンスが、AWSのバックアップが保存されているリージョンにあることを確認します。
  3. 保存先のGitLabインスタンスが、バックアップデータが作成されたGitLabと全く同じバージョンとタイプ（CEまたはEE）を使用していることを確認します。例えば、CE 15.1.4。
  4. バックアップしたシークレットを移行先のGitLabインスタンスにリストアします。
  5. 移行先のGitLabインスタンスに同じリポジトリストレージが設定されていることを確認してください。追加のストレージも問題ありません。
  6. バックアップしたGitLabインスタンスにオブジェクトストレージに保存されたBlobがあった場合、オブジェクトストレージがそれらの種類のBlob用に設定されていることを確認してください。
  7. バックアップされたGitLabインスタンスにファイルシステムに保存されたblobがあった場合、NFSが設定されていることを確認してください。

  8. 新しいシークレットや設定を使用し、リストア中の予期せぬ設定変更を避けるため：

    • すべてのノードへのLinuxパッケージのインストール：
      1. インストール先の GitLab インスタンスを再設定します。
      2. デスティネーションGitLabインスタンスを再起動します。

    • Helmチャート（Kubernetes）のインストール：

      1. すべてのGitLab Linuxパッケージノードで、実行します：

        sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

      2. Chartをデプロイして、GitLabインスタンスが稼働していることを確認します。以下のコマンドを実行して、Toolboxポッドが有効で実行されていることを確認します：

        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

      3. Webservice、Sidekiq、Toolboxポッドを再起動する必要があります。これらのポッドを再起動する最も安全な方法は、実行することです：

        kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
kubectl delete pods -lapp=toolbox,release=<helm release name>

  9. デスティネーションのGitLabインスタンスがまだ動作することを確認します。例えば

  10. PostgreSQL データベースに接続する GitLab サービスを停止します。

    • PumaまたはSidekiqが稼働しているすべてのノードでLinuxパッケージのインストールを実行します：

       sudo gitlab-ctl stop

    • Helmチャート（Kubernetes）のインストール：

      1. その後の再起動のために、データベースクライアントの現在のレプリカ数をメモしておきます：

        kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'

      2. ロ ッ ク に よ る 復元処理の妨げを防ぐ ために、 デー タ ベース の ク ラ イ ア ン ト を停止 し ます：

        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0

オブジェクト・ストレージ・データのリストア

各バケットはAWS内に個別のバックアップとして存在し、各バックアップは既存または新規のバケットにリストアすることができます。

  1. バケットをリストアするには、適切な権限を持つIAMロールが必要です：

    • AWSBackupServiceRolePolicyForBackup
    • AWSBackupServiceRolePolicyForRestores
    • AWSBackupServiceRolePolicyForS3Restore
    • AWSBackupServiceRolePolicyForS3Backup
  2. 既存のバケットを使用する場合は、アクセス制御リストが有効になっている必要があります。
  3. ビルトインツールを使用してS3バケットをリストアします。
  4. リストアジョブの実行中に、PostgreSQLデータのリストアに進むことができます。

PostgreSQLデータのリストア

  1. 新しいRDSインスタンスを作成する組み込みツールを使用して、AWS RDSデータベースをリストアします。

  2. 新しいRDSインスタンスは異なるエンドポイントを持っているので、新しいデータベースを指すようにデスティネーションのGitLabインスタンスを再設定する必要があります：

  3. 次に進む前に、新しいRDSインスタンスが作成され、使用できるようになるまで待ちます。

Git リポジトリの復元

復元するノードを選択または作成します：

Git リポジトリをリストアするには：

  1. ノードに、Gitリポジトリの.tar ファイルとその抽出データの両方を保存するのに十分なストレージが接続されていることを確認します。
  2. GitLab RailsノードにSSH接続します。
  3. オブジェクトストレージデータのリストアの一環として、GitリポジトリのGitLabバックアップ.tar ファイルを含むバケットをリストアしておく必要があります。

  4. バックアップ.tar ファイルをバケットからgitlab.rb 設定gitlab_rails['backup_path']に記述したバックアップ・ディレクトリにダウンロードします。デフォルトは/var/opt/gitlab/backupsです。バックアップファイルの所有者はgit ユーザーでなければなりません。

    sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git:git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar

  5. 復元したいバックアップのタイムスタンプを指定して、バックアップを復元します：

    caution
    リストアコマンドは、インストールがPgBouncerを使用している場合、パフォーマンス上の理由、またはPatroniクラスターで使用する場合、追加のパラメータが必要です。
    # This command will overwrite the contents of your GitLab database!
# NOTE: "_gitlab_backup.tar" is omitted from the name
sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce

    バックアップしたtarファイルとインストールしたGitLabのバージョンに不一致がある場合、restoreコマンドはエラーメッセージを出して中断します。正しいGitLabのバージョンをインストールしてから、もう一度試してください。

  6. GitLabを再起動して確認してください：

    • Linux パッケージのインストール：

      1. すべてのPumaまたはSidekiqノードで実行します：

        sudo gitlab-ctl restart

      2. 1つのPumaまたはSidekiqノードで実行します：

        sudo gitlab-rake gitlab:check SANITIZE=true

    • Helmチャート（Kubernetes）のインストール：

      1. 前提条件」に記載したレプリカ数を使用して、停止したデプロイを開始します：

        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<original value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<original value>

      2. Toolboxポッドで実行します：

        sudo gitlab-rake gitlab:check SANITIZE=true

  7. 特に、/etc/gitlab/gitlab-secrets.json がリストアされた場合、または別のサーバーがリストアの対象となった場合に、データベースの値が復号化できることを確認します：

    • Linuxパッケージ・インストールの場合、PumaまたはSidekiqノードで実行します：

       sudo gitlab-rake gitlab:doctor:secrets

    • Helmチャート（Kubernetes）のインストールの場合、Toolboxポッドで、以下を実行します：

       sudo gitlab-rake gitlab:doctor:secrets

  8. 保証を強化するために、アップロードされたファイルの整合性チェックを実行できます：

    • Linuxパッケージ・インストールの場合、PumaまたはSidekiqノードで実行します：

       sudo gitlab-rake gitlab:artifacts:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check

    • Helmチャート（Kubernetes）のインストールの場合、これらのコマンドはすべての行を繰り返し実行するため時間がかかることがあるので、ToolboxポッドではなくGitLab Railsノードで以下のコマンドを実行してください：

       sudo gitlab-rake gitlab:artifacts:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check

    見つからないファイルや破損したファイルが見つかっても、必ずしもバックアップとリストアプロセスが失敗したとは限りません。例えば、ソースGitLabインスタンス上でファイルが見つからないか、壊れている可能性があります。以前のバックアップを相互参照する必要があるかもしれません。GitLabを新しい環境にマイグレーションする場合、ソースGitLabインスタンスで同じチェックを実行して、整合性チェックの結果が既存のものなのか、バックアップとリストアプロセスに関連しているのかを判断することができます。

リストアは完了するはずです。