GitLabのバックアップとリストア

あなたのソフトウェアや組織は、GitLabインスタンス内のデータに依存しています。このデータを以下のような不利なイベントから確実に保護する必要があります：

  • 破損したデータ
  • 誤ってデータを削除
  • ランサムウェア攻撃
  • 予期せぬクラウドプロバイダーのダウンタイム

バックアップを含むディザスタリカバリプランによって、これらのリスクをすべて軽減することができます。

GitLabのバックアップ

GitLabのバックアップの詳細については、GitLabのバックアップをご覧ください。

GitLabのリストア

GitLabのリストアの詳細については、Restore GitLabをご覧ください。

新しいサーバーへのマイグレーション

GitLabバックアップとリストアを使って、インスタンスを新しいサーバーにマイグレーションすることができます。このセクションでは、GitLabデプロイを単一サーバーで実行している場合の典型的な手順の概要を説明します。GitLab Geoを実行している場合、計画的なフェイルオーバーのためのGeoディザスタリカバリという選択肢もあります。

caution
複数のサーバーが同時に接続し、同じデータを処理する可能性があるような、新旧両方のサーバーによる協調しないデータ処理を避けてください。例えば、受信メールを使用する場合、両方のGitLabインスタンスが同時にメールを処理していると、両方のインスタンスが何らかのデータを見逃すことになります。この種の問題は、パッケージ化されていないデータベースやパッケージ化されていないRedisインスタンス、パッケージ化されていないSidekiqなど、他のサービスでも発生する可能性があります。

前提条件：

  • マイグレーションを行う前に、ブロードキャストメッセージバナーで今後の定期メンテナンスをユーザーに通知することを検討してください。
  • バックアップが完全で最新であることを確認してください。破壊的なコマンド（rm など）が誤って実行された場合に備えて、完全なシステムレベルのバックアップを作成するか、マイグレーションに関係するすべてのサーバーのスナップショットを取得してください。

新しいサーバーの準備

新しいサーバーを準備します：

  1. 中間者攻撃の警告を回避するために、古いサーバーからSSH ホスト鍵をコピーします。手順の例については、「プライマリサイトの SSH ホスト鍵を手動で複製する」を参照してください。
  2. GitLabをインストールし、 受信メール以外の設定を行います：
    1. GitLabをインストールします。
    2. /etc/gitlab ファイルを旧サーバーから新サーバーにコピーして設定し、必要に応じて更新してください。詳しくはLinuxパッケージインストールのバックアップとリストアの説明をお読みください。
    3. 該当する場合は、受信メールを無効にします。

    4. バックアップとリストア後の初回起動時に、新しいCI/CDジョブの開始をブロックします。/etc/gitlab/gitlab.rb を編集し、以下を設定します：

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

    5. GitLab を再設定します：

      sudo gitlab-ctl reconfigure

  3. GitLabを停止し、不必要で意図しないデータ処理を避けることができます：

    sudo gitlab-ctl stop

  4. RedisデータベースとGitLabバックアップファイルを受信できるように新しいサーバーを設定します：

    sudo rm -f /var/opt/gitlab/redis/dump.rdb
sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups

旧サーバーからのコンテンツの準備と転送

  1. 古いサーバーの最新のシステムレベルバックアップまたはスナップショットがあることを確認します。
  2. GitLabエディションでサポートされている場合は、メンテナンスモードを有効にしてください。
  3. 新しいCI/CDジョブの開始をブロックします：

    1. /etc/gitlab/gitlab.rbを編集し、以下を設定します：

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

    2. GitLab を再設定します：

      sudo gitlab-ctl reconfigure
  4. 定期的なバックグラウンドジョブを無効にしました：
    1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
    2. Admin Areaを選択します。
    3. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
    4. Sidekiqダッシュボードで、［Cron］タブを選択し、［Disable All］を選択します。
  5. 現在実行中のCI/CDジョブが完了するまで待つか、完了していないジョブが失われる可能性があることを受け入れます。現在実行中のジョブを表示するには、左サイドバーで[概要] > [ジョブ]を選択し、[実行中]を選択します。
  6. Sidekiqジョブが終了するまで待ちます：
    1. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
    2. Sidekiqダッシュボードの下で、[キュー]、[ライブ・ポール]の順に選択します。これらのキューには、ユーザーによって提出されたジョブがコンテナされています。これらのジョブが完了する前にシャットダウンすると、ジョブが失われる可能性があります。マイグレーション後の検証のため、Sidekiqダッシュボードに表示される数字をメモしておいてください。

  7. 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

  8. GitLabのバックアップを作成します：

    sudo gitlab-backup create

  9. 以下の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

  10. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

  11. 全てのサービスが停止していることを確認し、実行中のサービスがないことを確認します：

    sudo gitlab-ctl status

  12. 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

新しいサーバーにデータをリストア

  1. 適切なファイルシステム権限を復元します：

    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
  2. GitLabバックアップを復元します。
  3. Redisデータベースが正しくリストアされたことを確認します：
    1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
    2. Admin Areaを選択します。
    3. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
    4. Sidekiqダッシュボードで、数値が旧サーバーで表示されていたものと一致していることを確認します。
    5. Sidekiqダッシュボードで、[cron]、[Enable All]の順に選択し、定期的なバックグラウンドジョブを再度有効にします。
  4. GitLabインスタンスでの読み取り専用オペレーションが期待通りに動作することをテストします。例えば、プロジェクトリポジトリファイル、マージリクエスト、イシューをブラウズします。
  5. メンテナンスモードを無効にします。
  6. GitLabインスタンスが期待通りに動作していることをテストします。
  7. 該当する場合は、受信メールを再度有効にして、期待通りに動作しているかテストしてください。
  8. DNSまたはロードバランサーを更新して、新しいサーバーを指すようにします。

  9. 以前に追加したカスタム 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"

  10. GitLab を再設定します：

    sudo gitlab-ctl reconfigure
  11. 定期メンテナンスのブロードキャストメッセージバナーを削除しました。

その他の注意事項

このドキュメントはGitLab Community EditionとEnterprise Edition用です。私たちはGitLab.comをバックアップし、あなたのデータのセキュリティを確保しています。しかし、これらの方法を使ってGitLab.comから自分でデータをエクスポートしたりバックアップしたりすることはできません。

イシューはデータベースに保存され、Git自体に保存することはできません。