GitLabインストールのバックアップ

GitLabのバックアップは、チャートで提供されるToolboxポッドでbackup-utilityコマンドを実行することで取得されます。バックアップは、このチャートのCron based backup機能を有効にすることで自動化することもできます。

初めてバックアップを実行する前に、オブジェクトストレージへのアクセスを許可するようにToolboxが適切に設定されていることを確認する必要があります。

GitLab Helmチャートベースのインストールをバックアップするには、以下の手順に従ってください。

バックアップを作成します

1. 次のコマンドを実行して、toolboxポッドが実行されていることを確認します。

   kubectl get pods -lrelease=<release_name>,app=toolbox

   <release_name>をHelmリリースの名前に置き換えます。通常はgitlabです。

2. バックアップユーティリティを実行します

   kubectl exec <Toolbox pod name> -it -- backup-utility

3. オブジェクトストレージサービスのgitlab-backupsバケットにアクセスし、tarballが追加されていることを確認します。<backup_ID>_gitlab_backup.tar形式で命名されます。バックアップについてお読みください。

4. このtarballは復元に必要です。

Cronベースのバックアップ

このチャートでは、Kubernetesスケジュールで定義されているように、cronベースのバックアップを定期的に実行できるようにすることができます。

次のパラメータを設定する必要があります:

• gitlab.toolbox.backups.cron.enabled: cronベースのバックアップを有効にするには、trueに設定します
• gitlab.toolbox.backups.cron.schedule: Kubernetesスケジュールドキュメントに従って設定します
• gitlab.toolbox.backups.cron.extraArgs: 必要に応じて、バックアップユーティリティに追加の引数を設定します（--skip dbや--s3tool awscliなど）。

バックアップユーティリティの追加の引数

バックアップユーティリティは、いくつかの追加の引数を取ることができます。

コンポーネントの除外

--skip引数を使用してコンポーネントを除外します。有効なコンポーネント名は、バックアップからの特定のデータの除外にあります。

各コンポーネントには、独自の--skip引数が必要です。例:

kubectl exec <Toolbox pod name> -it -- backup-utility --skip db --skip lfs

バックアップのみをクリーンアップする

新しいバックアップを作成せずに、バックアップのクリーンアップを実行します。

kubectl exec <Toolbox pod name> -it -- backup-utility --cleanup

使用するS3ツールを指定する

backup-utilityコマンドは、オブジェクトストレージに接続するために、デフォルトでs3cmdを使用します。s3cmdが他のS3ツールよりも信頼性が低い場合に、この追加の引数をオーバーライドする必要がある場合があります。

GitLabがS3バケットをCIジョブアーティファクトストレージとして使用し、デフォルトのs3cmdCLIツールが使用されている場合、ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist.でバックアップジョブがクラッシュする既知の問題があります。s3cmdからawscliにスイッチすると、バックアップジョブを正常に実行できます。詳しくは、issue 3338をご覧ください。

使用するS3 CLIツールは、s3cmdまたはawscliのいずれかです。

kubectl exec <Toolbox pod name> -it -- backup-utility --s3tool awscli

awscliでのMinIOの使用

awscliを使用するときに、オブジェクトストレージとしてMinIOを使用するには、次のパラメータを設定します:

gitlab:
  toolbox:
    extraEnvFrom:
      AWS_ACCESS_KEY_ID:
        secretKeyRef:
          name: <MINIO-SECRET-NAME>
          key: accesskey
      AWS_SECRET_ACCESS_KEY:
        secretKeyRef:
          name: <MINIO-SECRET-NAME>
          key: secretkey
    extraEnv:
      AWS_DEFAULT_REGION: us-east-1 # MinIO default
    backups:
      cron:
        enabled: true
        schedule: "@daily"
        extraArgs: "--s3tool awscli --aws-s3-endpoint-url <MINIO-INGRESS-URL>"

awscliによるデータ整合性保護

toolboxに含まれるawscliツールの最近のバージョンでは、デフォルトでデータ整合性保護が適用されます。オブジェクトストレージサービスがこの機能をサポートしていない場合、この要件は次のようにして無効にできます:

extraEnv:
  AWS_REQUEST_CHECKSUM_CALCULATION: WHEN_REQUIRED

この設定は、toolboxポッドのextraEnvまたはグローバルのextraEnvのいずれかになります。

サーバー側のリポジトリのバックアップ

大規模なリポジトリのバックアップをバックアップアーカイブに保存するのではなく、各リポジトリをホストするGitalyノードがバックアップを作成し、オブジェクトストレージにストリーミングできるように設定することが可能です。これにより、バックアップの作成と復元に必要なネットワークリソースを削減できます。

サーバー側のリポジトリのバックアップを作成するを参照してください。

その他の引数

使用可能な引数の完全なリストを表示するには、次のコマンドを実行します:

kubectl exec <Toolbox pod name> -it -- backup-utility --help

シークレットをバックアップします。

セキュリティ上の予防措置として、railsシークレットのコピーも保存する必要があります。これらはバックアップには含まれていません。データベースを含む完全なバックアップとシークレットのコピーは別々に保管することをお勧めします。

1. railsシークレットのオブジェクト名を検索します

   kubectl get secrets | grep rails-secret

2. railsシークレットのコピーを保存します

   kubectl get secrets <rails-secret-name> -o jsonpath="{.data['secrets\.yml']}" | base64 --decode > gitlab-secrets.yaml

3. gitlab-secrets.yamlを安全な場所に保管してください。これはバックアップを復元するために必要です。

追加情報

• GitLabチャートのバックアップ / 復元の概要
• GitLabインストールを復元する