GitLabのバックアップとリストア
あなたのソフトウェアや組織は、GitLabインスタンス内のデータに依存しています。このデータを以下のような不利なイベントから確実に保護する必要があります:
- 破損したデータ
- 誤ってデータを削除
- ランサムウェア攻撃
- 予期せぬクラウドプロバイダーのダウンタイム
バックアップを含むディザスタリカバリプランによって、これらのリスクをすべて軽減することができます。
GitLabのバックアップ
GitLabのバックアップの詳細については、GitLabのバックアップをご覧ください。
GitLabのリストア
GitLabのリストアの詳細については、Restore GitLabをご覧ください。
新しいサーバーへのマイグレーション
GitLabバックアップとリストアを使って、インスタンスを新しいサーバーにマイグレーションすることができます。このセクションでは、GitLabデプロイを単一サーバーで実行している場合の典型的な手順の概要を説明します。GitLab Geoを実行している場合、計画的なフェイルオーバーのためのGeoディザスタリカバリという選択肢もあります。
前提条件:
- マイグレーションを行う前に、ブロードキャストメッセージバナーで今後の定期メンテナンスをユーザーに通知することを検討してください。
- バックアップが完全で最新であることを確認してください。破壊的なコマンド(
rm
など)が誤って実行された場合に備えて、完全なシステムレベルのバックアップを作成するか、マイグレーションに関係するすべてのサーバーのスナップショットを取得してください。
新しいサーバーの準備
新しいサーバーを準備します:
- 中間者攻撃の警告を回避するために、古いサーバーからSSH ホスト鍵をコピーします。手順の例については、「プライマリサイトの SSH ホスト鍵を手動で複製する」を参照してください。
-
GitLabをインストールし、 受信メール以外の設定を行います:
- GitLabをインストールします。
-
/etc/gitlab
ファイルを旧サーバーから新サーバーにコピーして設定し、必要に応じて更新してください。詳しくはLinuxパッケージインストールのバックアップとリストアの説明をお読みください。 - 該当する場合は、受信メールを無効にします。
-
バックアップとリストア後の初回起動時に、新しいCI/CDジョブの開始をブロックします。
/etc/gitlab/gitlab.rb
を編集し、以下を設定します:nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n }\n"
-
GitLab を再設定します:
sudo gitlab-ctl reconfigure
-
GitLabを停止し、不必要で意図しないデータ処理を避けることができます:
sudo gitlab-ctl stop
-
RedisデータベースとGitLabバックアップファイルを受信できるように新しいサーバーを設定します:
sudo rm -f /var/opt/gitlab/redis/dump.rdb sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups
旧サーバーからのコンテンツの準備と転送
- 古いサーバーの最新のシステムレベルバックアップまたはスナップショットがあることを確認します。
- GitLabエディションでサポートされている場合は、メンテナンスモードを有効にしてください。
- 新しいCI/CDジョブの開始をブロックします:
-
/etc/gitlab/gitlab.rb
を編集し、以下を設定します:nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n }\n"
-
GitLab を再設定します:
sudo gitlab-ctl reconfigure
-
- 定期的なバックグラウンドジョブを無効にしました:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
- Sidekiqダッシュボードで、[Cron]タブを選択し、[Disable All]を選択します。
- 現在実行中のCI/CDジョブが完了するまで待つか、完了していないジョブが失われる可能性があることを受け入れます。現在実行中のジョブを表示するには、左サイドバーで[概要] > [ジョブ]を選択し、[実行中]を選択します。
- Sidekiqジョブが終了するまで待ちます:
- 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
- Sidekiqダッシュボードの下で、[キュー]、[ライブ・ポール]の順に選択します。これらのキューには、ユーザーによって提出されたジョブがコンテナされています。これらのジョブが完了する前にシャットダウンすると、ジョブが失われる可能性があります。マイグレーション後の検証のため、Sidekiqダッシュボードに表示される数字をメモしておいてください。
-
Redisデータベースをディスクにフラッシュし、マイグレーションに必要なサービス以外のGitLabを停止します:
sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket save && sudo gitlab-ctl stop && sudo gitlab-ctl start postgresql && sudo gitlab-ctl start gitaly
-
GitLabのバックアップを作成します:
sudo gitlab-backup create
-
以下のGitLabサービスを無効にし、意図しない再起動を防ぐには、
/etc/gitlab/gitlab.rb
の一番下に以下を追加します:alertmanager['enable'] = false gitlab_exporter['enable'] = false gitlab_pages['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false logrotate['enable'] = false gitlab_rails['incoming_email_enabled'] = false nginx['enable'] = false node_exporter['enable'] = false postgres_exporter['enable'] = false postgresql['enable'] = false prometheus['enable'] = false puma['enable'] = false redis['enable'] = false redis_exporter['enable'] = false registry['enable'] = false sidekiq['enable'] = false
-
GitLab を再設定します:
sudo gitlab-ctl reconfigure
-
全てのサービスが停止していることを確認し、実行中のサービスがないことを確認します:
sudo gitlab-ctl status
-
RedisデータベースとGitLabのバックアップを新しいサーバーに転送します:
sudo scp /var/opt/gitlab/redis/dump.rdb <your-linux-username>@new-server:/var/opt/gitlab/redis sudo scp /var/opt/gitlab/backups/your-backup.tar <your-linux-username>@new-server:/var/opt/gitlab/backups
新しいサーバーにデータをリストア
-
適切なファイルシステム権限を復元します:
sudo chown gitlab-redis /var/opt/gitlab/redis sudo chown gitlab-redis:gitlab-redis /var/opt/gitlab/redis/dump.rdb sudo chown git:root /var/opt/gitlab/backups sudo chown git:git /var/opt/gitlab/backups/your-backup.tar
- GitLabバックアップを復元します。
- Redisデータベースが正しくリストアされたことを確認します:
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
- Sidekiqダッシュボードで、数値が旧サーバーで表示されていたものと一致していることを確認します。
- Sidekiqダッシュボードで、[cron]、[Enable All]の順に選択し、定期的なバックグラウンドジョブを再度有効にします。
- GitLabインスタンスでの読み取り専用オペレーションが期待通りに動作することをテストします。例えば、プロジェクトリポジトリファイル、マージリクエスト、イシューをブラウズします。
- メンテナンスモードを無効にします。
- GitLabインスタンスが期待通りに動作していることをテストします。
- 該当する場合は、受信メールを再度有効にして、期待通りに動作しているかテストしてください。
- DNSまたはロードバランサーを更新して、新しいサーバーを指すようにします。
-
以前に追加したカスタム NGINX 設定を削除して、新しい CI/CD ジョブの開始をブロックしないようにします:
# The following line must be removed nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n }\n"
-
GitLab を再設定します:
sudo gitlab-ctl reconfigure
- 定期メンテナンスのブロードキャストメッセージバナーを削除しました。
その他の注意事項
このドキュメントはGitLab Community EditionとEnterprise Edition用です。私たちはGitLab.comをバックアップし、あなたのデータのセキュリティを確保しています。しかし、これらの方法を使ってGitLab.comから自分でデータをエクスポートしたりバックアップしたりすることはできません。
イシューはデータベースに保存され、Git自体に保存することはできません。