新しいサーバーに移行する

GitLabのバックアップと復元機能を使用して、インスタンスを新しいサーバーに移行できます。このセクションでは、単一のサーバーで実行されているGitLabデプロイの一般的な手順の概要を説明します。GitLab Geoを実行している場合、代替手段として計画フェイルオーバーにおけるGeoディザスターリカバリーがあります。移行手段としてGeoを選択する前に、すべてのサイトがGeoの要件を満たしていることを確認する必要があります。

新旧両方のサーバーが連携することなく個別にデータを処理することは避けてください。複数のサーバーが同時に接続して同じデータを処理してしまう可能性があります。たとえば、受信メールを使用している場合、両方のGitLabインスタンスが同時にメールを処理すると、どちらのインスタンスでも一部のデータが失われる可能性があります。このような問題は、パッケージ化されていないデータベース、パッケージ化されていないRedisインスタンス、パッケージ化されていないSidekiqなど、他のサービスでも発生する可能性があります。

前提要件:

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

新しいサーバーを準備する

新しいサーバーを準備するには、次の手順に従います:

中間者攻撃に関する警告を避けるため、旧サーバーからSSHホストキーをコピーします。手順の例については、プライマリサイトのSSHホストキーを手動でレプリケートするを参照してください。
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
```
不要かつ意図しないデータ処理を避けるため、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ジョブが開始されないようにブロックします:
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
```
定期的なバックグラウンドジョブを無効にします:
1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
2. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択して、Sidekiqダッシュボードを表示します。
3. Sidekiqダッシュボードの上部メニューで、Cronを選択します。
4. Sidekiqダッシュボードの右上にあるDisable All（すべて無効にする）を選択します。
実行中のCI/CDジョブが完了するまで待ちます。そうしないと、完了していないジョブが失われる可能性があります。実行中のすべてのジョブを表示するには:
1. 左側のサイドバーで、CI/CD > ジョブを選択します。
2. フィルターバーで、ステータス > 実行中を選択します。
Sidekiqジョブが完了するのを待ちます:
1. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。
2. Sidekiqダッシュボードの上部メニューで、Queues（キュー）を選択します。
3. Sidekiqダッシュボードの右上にあるLive Poll（ライブポール）を選択します。ビジーおよびEnqueuedが0になるまで待ちます。これらのキューにはユーザーから送信された作業が含まれています。これらのジョブが完了する前にシャットダウンすると、作業が失われる可能性があります。移行後の検証に備えて、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
gitaly['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データベースのバックアップを転送する前に、新しいサーバー上のRedisを停止します:
```
sudo gitlab-ctl stop redis
```

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

Gitやオブジェクトのデータ量が多いインスタンスの場合

GitLabインスタンスのローカルボリューム上に大量のデータがある場合、たとえば1 TBを超えるようなケースでは、バックアップに時間がかかることがあります。そのような場合は、新しいインスタンスの適切なボリュームにデータを転送する方が簡単なこともあります。

手動で移行する必要がある主なボリュームは次のとおりです:

すべてのGitデータを含む/var/opt/gitlab/git-dataディレクトリ。Gitデータの破損を防ぐために、リポジトリの移動に関するドキュメントの該当セクションを必ずお読みください。
アーティファクトなどのオブジェクトデータを含む/var/opt/gitlab/gitlab-rails/sharedディレクトリ。
Linuxパッケージに含まれているバンドル版PostgreSQLを使用している場合は、/var/opt/gitlab/postgresql/dataにあるPostgreSQLデータディレクトリも移行する必要があります。

すべてのGitLabサービスが停止したら、rsyncなどのツールを使用するか、ボリュームスナップショットをマウントして、新しい環境にデータを移行できます。

新しいサーバーでデータを復元する

適切なファイルシステムの権限を復元します:

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

Redisを起動します:
```
sudo gitlab-ctl start redis
```
Redisはdump.rdbを自動的に検出して復元します。
GitLabバックアップを復元します。
Redisデータベースが正しく復元されたことを確認します:
1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にあるアバターを選択し、管理者を選択します。
2. 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。
3. Sidekiqダッシュボードで、表示されている数値が旧サーバーの数値と一致することを確認します。
4. 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
```
スケジュール済みメンテナンスに関するブロードキャストメッセージバナーを削除します。