Help us learn about your current experience with the documentation. Take the survey.

迁移到新服务器

您可以使用 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 <您的 Linux 用户名> /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
```

禁用周期性后台作业：
1. 在左侧边栏的底部，选择 管理员。
2. 在左侧边栏中，选择监控 > 后台作业。
3. 在 Sidekiq 仪表板下，选择 Cron 标签页，然后选择 全部禁用。
等待正在运行的 CI/CD 作业完成，或者接受未完成作业可能会丢失的事实。要查看正在运行的作业，请在左侧边栏中选择概览 > 作业，然后选择 运行中。
等待 Sidekiq 作业完成：
1. 在左侧边栏中，选择监控 > 后台作业。
2. 在 Sidekiq 仪表板下，选择队列，然后选择 实时轮询。等待 Busy（繁忙）和 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
```

备份完成后，通过在 /etc/gitlab/gitlab.rb 文件底部添加以下内容来禁用以下 GitLab 服务，并防止其意外重启：

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 <您的 Linux 用户名>@new-server:/var/opt/gitlab/redis
sudo scp /var/opt/gitlab/backups/your-backup.tar <您的 Linux 用户名>@new-server:/var/opt/gitlab/backups

对于包含大量 Git 和对象数据的实例

如果您的 GitLab 实例在本地卷上有大量数据（例如，大于 1 TB），备份可能会花费很长时间。在这种情况下，您可能会发现将数据直接传输到新实例上的相应卷会更加容易。

您可能需要手动迁移的主要卷包括：

/var/opt/gitlab/git-data 目录，其中包含所有 Git 数据。请务必阅读移动仓库文档部分，以消除 Git 数据损坏的可能性。
/var/opt/gitlab/gitlab-rails/shared 目录，其中包含对象数据，例如制品（artifacts）。
如果您使用的是 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，然后选择 全部启用 以重新启用周期性后台作业。
测试 GitLab 实例上的只读操作是否按预期工作。例如，浏览项目仓库文件、合并请求和议题。
如果之前启用了维护模式，请将其禁用。
测试 GitLab 实例是否按预期工作。
如果适用，请重新启用收件邮件并测试其是否按预期工作。
更新您的 DNS 或负载均衡器，使其指向新服务器。

通过移除之前添加的自定义 NGINX 配置来解除对新 CI/CD 作业启动的阻止：

# 必须移除以下行
nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

重新配置 GitLab：
```
sudo gitlab-ctl reconfigure
```
移除计划维护的广播消息横幅。