バックアップとリストア
このドキュメントでは、CNG へのバックアップと CNG からのリストアの技術的な実装について説明します。
ツールボックスポッド
toolboxチャートはポッドをクラスターにデプロイします。このポッドは、クラスター内の他のコンテナとのインタラクションのエントリポイントとして機能します。
このポッドを使用して、ユーザーは以下のコマンドを実行できます。kubectl exec -it <pod name> -- <arbitrary command>
Toolboxイメージからコンテナを実行します。
イメージには、ユーザーからコマンドとして呼び出されるカスタム・スクリプトがいくつか含まれています。これらのスクリプトは、Rakeタスクの実行、バックアップ、リストア、およびオブジェクト・ストレージとやり取りするためのヘルパー・スクリプトです。
バックアップユーティリティ
バックアップユーティリティは、タスクランナーコンテナ内のスクリプトの1つで、その名前が示すように、バックアップを実行するために使用されるスクリプトですが、既存のバックアップのリストアも処理します。
バックアップ
バックアップ・ユーティリティ・スクリプトを引数なしで実行すると、バックアップtarが作成され、オブジェクトストレージにアップロードされます。
実行順序
バックアップは以下の手順で順番に行われます:
- GitLab backup Rake タスクを使ってデータベースをバックアップします。
- GitLab backup Rakeタスクを使ってリポジトリをバックアップします。
- オブジェクトストレージバックエンドごとに
- オブジェクト・ストレージ・バックエンドがスキップするようにマークされている場合は、このストレージ・バックエンドをスキップします。
- 既存のデータを対応するオブジェクトストレージのバケットに Tar します。
<bucket-name>.tar
- tarをディスク上のバックアップ場所に移動
- GitLabのバージョン、バックアップの時間、スキップされた項目を特定するメタデータを含む
backup_information.yml
。 - 個々の tar ファイルを含む tar ファイルを作成します。
backup_information.yml
- 出来上がった tar ファイルをオブジェクトストレージ
gitlab-backups
バケットにアップロードします。
コマンドライン引数
-
--skip <component>
バックアップ処理でスキップしたいコンポーネントごとに
--skip <component>
を使用すると、バックアップ処理の一部をスキップできます。スキップ可能なコンポーネントは、データベース (db
)、リポジトリ (repositories
)、オブジェクト・ストレージ (registry
,uploads
,artifacts
,lfs
,packages
,external_diffs
,terraform_state
, またはci_secure_files
) のいずれかです。 -
-t <timestamp-override-value>
このフラグを指定すると、作成されるバックアップの名前は
<timestamp-override-value>_gitlab_backup.tar
になります。このフラグを指定すると、作成されるバックアップの名前はYYYY_mm_dd
になります。デフォルト値は現在のUNIXタイムスタンプで、現在の日付を に後置整形したものです。 -
--backend <backend>
バックアップに使用するオブジェクト・ストレージ・バックエンドを設定します。
s3
またはgcs
のいずれかを指定できます。デフォルトはs3
です。 -
--storage-class <storage-class-name>
--storage-class <storage-class-name>
を使用して、バックアップを保存するストレージ・クラスを指定することもできます。未指定の場合、ストレージ・バックエンドのデフォルトが使用されます。このストレージクラス名は、指定したバックエンドのストレージクラス引数にそのまま渡されます。
GitLab バックアップバケット
バックアップを保存するバケットのデフォルト名はgitlab-backups
です。これはBACKUP_BUCKET_NAME
環境変数を使って設定できます。
Google Cloud Storageへのバックアップ
デフォルトでは、バックアップユーティリティはs3cmd
を使用してオブジェクトストレージからアーティファクトをアップロードおよびダウンロードします。これは Google Cloud Storage(GCS)で動作しますが、認証と作成者に好ましくない妥協を強いる Interoperability API を使用する必要があります。バックアップに Google クラウド ストレージを使用する場合、環境変数BACKUP_BACKEND
をgcs
に設定することで、アーティファクトのアップロードとダウンロードにクラウド ストレージ ネイティブ CLIgsutil
を使用するようにバックアップ ユーティリティ スクリプトを設定できます。
復元
バックアップユーティリティは引数--restore
を与えると、既存のバックアップから実行中のインスタンスへのリストアを試みます。このバックアップは、バックアップされたインスタンスと実行中のインスタンスの両方が同じバージョンの GitLab を実行していれば、Linux パッケージのインストールや CNG Helm chart のインストールから行うことができます。リストアでは、-t <backup-name>
を使ってバックアップバケット内のファイルを、-f <url>
を使ってリモート URL を指定します。
-t
パラメータが与えられると、オブジェクトストレージのバックアップバケットを検索し、そのような名前のバックアップタールを探します。-f
パラメータが指定された場合は、指定された URL がコンテナからアクセス可能な場所にあるバックアップ tar の有効な URI であることを期待します。
バックアップtarを取得した後の実行シーケンスは次のとおりです:
- リポジトリとデータベースについては、GitLabバックアップRakeタスクを実行します。
- 各オブジェクトストレージバックエンドについて:
- 対応するオブジェクトストレージのバケットに既存のデータを tar でコピーします。
<backup-name>.tar
- オブジェクトストレージの
tmp
バケットにアップロードします。 - 対応するバケットをクリーンアップ
- バックアップ内容を対応するバケツにリストアします。
- 対応するオブジェクトストレージのバケットに既存のデータを tar でコピーします。
tmp
リストアに失敗した場合、ユーザーはバックアップバケットのtmp
ディレクトリにあるデータを使って以前のバックアップに戻す必要があります。これは現在手動で行っています。