バックアップと復元

このドキュメントでは、CNGとの間でのバックアップとリストアの技術的な実装について説明します。

Toolboxポッド

toolbox chartは、ポッドをクラスタリングにデプロイします。このポッドは、クラスタリング内の他のコンテナとのインタラクションのエントリポイントとして機能します。

このポッドを使用すると、ユーザーはkubectl exec -it <pod name> -- <arbitrary command>を使用してコマンドを実行できます

Toolboxは、Toolbox imageからコンテナを実行します。

このイメージには、ユーザーがコマンドとして呼び出すcustom scriptsがいくつか含まれています。これらのスクリプトは、Rakeタスク、バックアップ、リストアの実行、およびオブジェクトストレージとのインタラクションのためのいくつかのヘルパースクリプト用です。

Backupユーティリティ

Backup utilityは、toolboxコンテナ内のスクリプトの1つであり、名前が示すように、バックアップを実行するために使用されるスクリプトですが、既存のバックアップのリストアも処理します。

バックアップ

引数なしで実行されたBackupユーティリティスクリプトは、バックアップtarを作成し、オブジェクトストレージにアップロードします。

実行順序

バックアップは、次の手順で順番に作成されます:

1. GitLab backup Rake taskを使用して、（スキップされていない場合）データベースをバックアップします
2. GitLab backup Rake taskを使用して、（スキップされていない場合）リポジトリをバックアップします
3. オブジェクトストレージバックエンドごとに、
   1. オブジェクトストレージバックエンドがスキップするようにマークされている場合は、このストレージバックエンドをスキップします。
   2. 対応するオブジェクトストレージバケット内の既存のデータをtarでアーカイブし、<bucket-name>.tarという名前を付けます
   3. tarをディスク上のバックアップ場所に移動します
4. backup_information.ymlファイルを作成します。これには、GitLabのバージョン、バックアップの時刻、スキップされた項目を識別するメタデータが含まれます。
5. 個々のtarファイルをbackup_information.ymlとともに含むtarファイルを作成します
6. 結果のtarファイルをオブジェクトストレージgitlab-backupsバケットにアップロードします。

コマンドライン引数

• --skip <component>

  バックアッププロセスでスキップするすべてのコンポーネントに対して--skip <component>を使用することにより、バックアッププロセスの一部をスキップできます。スキップ可能なコンポーネントは、Excluding specific data from the backupにあります。

• -t <timestamp-override-value>

  これにより、バックアップの名前を部分的に制御できます。このフラグを指定すると、作成されたバックアップの名前は<timestamp-override-value>_gitlab_backup.tarになります。デフォルト値は現在のUNIXタイムスタンプであり、現在のYYYY_mm_ddにフォーマットされた日付が後置されます。

• --backend <backend>

  バックアップに使用するオブジェクトストレージバックエンドを構成します。s3またはgcsのいずれかになります。デフォルトはs3です。

• --storage-class <storage-class-name>

  --storage-class <storage-class-name>を使用してバックアップが保存されるストレージクラスを指定することもでき、バックアップストレージのコストを節約できます。指定しない場合、ストレージバックエンドのデフォルトが使用されます。

  このストレージクラス名は、指定したバックエンドのストレージクラス引数にそのまま渡されます。

GitLabバックアップバケット

バックアップの保存に使用されるバケットのデフォルト名はgitlab-backupsです。これは、BACKUP_BUCKET_NAME環境変数を使用して構成可能です。

Google Cloud Storageへのバックアップ

デフォルトでは、Backupユーティリティはs3cmdを使用して、オブジェクトストレージからアーティファクトをアップロードおよびフェッチします。これはGoogle Cloud Storage（GCS）で動作しますが、相互運用性APIを使用する必要があり、認証と認可に望ましくない妥協が生じます。バックアップにGoogle Cloud Storageを使用する場合、環境変数BACKUP_BACKENDをgcsに設定することにより、Cloud StorageネイティブCLIであるgsutilを使用して、アーティファクトのアップロードとフェッチを行うように、Backupユーティリティスクリプトを構成できます。

復元する

Backupユーティリティは、引数--restoreが指定されると、実行中のインスタンスへの既存のバックアップからリストアを試みます。このバックアップは、バックアップされたインスタンスと実行中のインスタンスの両方が同じバージョンのGitLabを実行していることを考えると、LinuxパッケージのインストールまたはCNG Helm Chartのインストールのいずれかからのものにすることができます。リストアは、-t <backup-name>を使用したバックアップバケット内のファイル、または-f <url>を使用したリモートURLを想定しています。

-tパラメータが指定されている場合、その名前のバックアップtarについて、オブジェクトストレージ内のバックアップバケットを調べます。-fパラメータが指定されている場合、指定されたURIが、コンテナからアクセス可能な場所にあるバックアップtarの有効なURIであると想定します。

バックアップtarをフェッチした後、実行順序は次のとおりです:

1. リポジトリとデータベースの場合は、GitLab backup Rake taskを実行します
2. オブジェクトストレージバックエンドごとに、:
   • 対応するオブジェクトストレージバケット内の既存のデータをtarでアーカイブし、<backup-name>.tarという名前を付けます
   • オブジェクトストレージ内のtmpバケットにアップロードします
   • 対応するバケットをクリーンアップします
   • バックアップコンテンツを対応するバケットにリストアします