服务器迁移往往是运维和开发人员最头疼的时刻之一。想象一下 你的旧服务器像一头不堪重负的老牛，随时可能倒下而你必须把上面承载的所有代码仓库、CI/CD流水线以及团队成员的每一次提交，平安无损地转移到新的环境中。这听起来像是一场噩梦，对吧？特别是当你面对的是GitLab这样一个功能庞大、 组件复杂的DevOps平台时稍有不慎就可能导致数据丢失或者服务不可用，摸个底。。

但别担心，其实GitLab的数据迁移并没有想象中那么恐怖。只要掌握了正确的节奏，理清了其中的逻辑，这甚至可以成为一次轻松的“搬家”体验。今天我们就来深入探讨一下如何在Ubuntu环境下实现GitLab数据的平滑迁移与快速恢复。 我们都经历过... 这不仅仅是一次技术的操作，更是一场关于数据平安的保卫战。

迁移前的“排雷”工作：版本一致性是关键

在按下任何回车键之前， 我们必须先谈谈一个至关重要，却经常被新手忽略的问题：版本一致性。这简直是GitLab迁移中的“铁律”。如果你旧服务器跑的是GitLab 14.8.2， 而新服务器你一时手快直接装了个最新的15.x版本，那么恭喜你，你大概率会遇到数据库结构不匹配导致的恢复失败，或者各种奇奇怪报错。

醉了... 所以第一步不是备份，而是“侦察”。你需要先登录到旧服务器，确认当前的GitLab版本。打开终端，输入以下命令：

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

记下这个版本号。比如输出是 14.8.2 那么你的新服务器上，必须安装精确到小版本号的 14.8.2。哪怕只是补丁版本号不同， 虽然有时候能成功，但官方建议最好保持完全一致，以避免潜在的数据库迁移脚本冲突。

如果新服务器需要安装特定版本， 不要直接用 apt-get install gitlab-ce主要原因是这会拉取最新版。你需要去GitLab的官方仓库， 找到对应版本的 .deb 包下载链接，或者配置好源后指定版本安装。这一步虽然繁琐，但能为你省去后续无数的麻烦，绝对是值得的，拭目以待。。

全量备份：不仅仅是代码， 更是心血

确认了版本之后我们就可以开始打包行李了。GitLab非常贴心地为我们提供了一个强大的备份工具， 琢磨琢磨。 能够将仓库、数据库、构建产物、用户配置等几乎所有东西打包成一个压缩文件。

在旧服务器上， 施行以下命令来创建备份：

sudo gitlab-rake gitlab:backup:create

这个过程可能需要一点时间，具体取决于你的仓库数量和体积。你可以去泡杯咖啡，或者盯着屏幕上滚动的日志发会儿呆。默认情况下生成的备份文件会存放在 /var/opt/gitlab/backups/ 目录下。文件名通常是一长串的时间戳加上版本号，格式类似 1658368484_2022_07_21_14.8.2_gitlab_backup.tar。请务必记住这个文件名的前缀，后面恢复时会用到它，太顶了。。

但是等等！这还没完。很多新手在这里就踩坑了。上面的命令只备份了“数据”，并没有备份“配置”。你的SMTP设置、LDAP配置、域名绑定等等，都存储在配置文件中。如果只恢复数据备份， 你会发现新服务器上的GitLab虽然数据有了但发不了邮件，连不上域控，甚至无法通过域名访问。

所以 你还需要手动备份以下关键文件：

# 备份主配置文件
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak
# 备份机密文件
sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.bak

特别是 gitlab-secrets.json它就像是GitLab的保险箱钥匙。如果没有这个文件， 即使恢复了数据库，GitLab也无法解密两步验证的密钥，或者导致CI/CD的Runner无法连接，那场面简直是一地鸡毛，纯属忽悠。。

数据传输：跨越山海的搬运

现在我们手里有了沉甸甸的备份包和配置文件。接下来就是要把它们从旧服务器搬运到新服务器。 太刺激了。 虽然可以用U盘，但更常见的方式是使用 scp 或 rsync 命令通过网络传输。

扯后腿。 假设你的新服务器IP是 192.168.1.100 你可以这样操作：

# 传输数据备份包
scp /var/opt/gitlab/backups/时间戳_gitlab_backup.tar user@192.168.1.100:/var/opt/gitlab/backups/
# 传输配置文件
scp /etc/gitlab/gitlab.rb user@192.168.1.100:/etc/gitlab/gitlab.rb.bak
scp /etc/gitlab/gitlab-secrets.json user@192.168.1.100:/etc/gitlab/gitlab-secrets.json.bak

传输大文件时网络波动总是让人心惊肉跳。如果文件特别大，建议使用 rsync主要原因是它支持断点续传。 太魔幻了。 看着进度条一点点跑满，那种感觉就像是看着自己的孩子慢慢长大一样，既焦急又期待。

在新服务器上“复活”：恢复的艺术

从一个旁观者的角度看... 数据到了新家，我们就可以开始着手恢复了。先说说确保你已经在新服务器上安装了与旧版本一致的GitLab。安装完成后先不要急着启动服务，我们需要先把配置文件放回去。

将刚才传输过来的配置文件覆盖到对应位置：

sudo cp /etc/gitlab/gitlab.rb.bak /etc/gitlab/gitlab.rb
sudo cp /etc/gitlab/gitlab-secrets.json.bak /etc/gitlab/gitlab-secrets.json

然后施行 gitlab-ctl reconfigure 来让配置生效。 一句话概括... 这一步会根据配置文件重新初始化GitLab的服务组件。

你想... 接下来是重头戏——恢复数据。在施行恢复之前，强烈建议停止GitLab的相关服务，防止在恢复过程中有新的数据写入导致冲突。你可以施行：

sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq

或者更干脆一点，直接 sudo gitlab-ctl stop 停止所有服务。

现在找到你上传到 /var/opt/gitlab/backups/ 目录下的那个备份文件。注意，恢复命令需要的是文件名中的时间戳前缀，而不是完整的文件名。 差点意思。 比如文件名是 1658368484_2022_07_21_14.8.2_gitlab_backup.tar 那么你的命令应该是：

sudo gitlab-rake gitlab:backup:restore BACKUP=1658368484_2022_07_21_14.8.2

拜托大家... 系统可能会问你一句 Do you want to continue ?毫不犹豫地输入 yes 并回车。接下来的屏幕输出可能会让你眼花缭乱，各种表结构的重建、数据的回滚。这时候你需要一点耐心，不要以为卡死了而强制中断。只要CPU和磁盘IO在跳动，它就在努力工作。

你没事吧？ 恢复完成后还有一个细节容易被遗忘：权限问题。有时候备份文件传输过来后 所有者可能变成了你上传时的用户，而不是GitLab专用的 git 用户。为了保险起见， 施行一下权限修正：

sudo chown -R git:git /var/opt/gitlab/backups

重启与验证：见证奇迹的时刻

走捷径。 当所有的命令都施行完毕，没有报错信息刺痛你的双眼时恭喜你，最艰难的部分已经过去了。现在 启动GitLab服务：

sudo gitlab-ctl start

或者使用之前提到的组合拳：

sudo gitlab-ctl reconfigure && sudo gitlab-ctl start

站在你的角度想... 稍等片刻，让服务完全启动。你可以通过 sudo gitlab-ctl status 查看所有组件的状态，确保它们都是 run: ... 的状态。如果有哪个服务亮起了红灯，那就需要去 /var/log/gitlab/ 下翻看日志找原因了。

不忍直视。 再说说打开浏览器，输入新服务器的域名或IP。当你看到熟悉的GitLab登录界面 输入旧服务器的账号密码成功进入，看到那些熟悉的仓库、Issue和Merge Request依然静静地躺在那里时那种如释重负的感觉简直无法言喻。

为了确保万无一失， 建议随机抽查几个项目，克隆一下代码，检查一下CI流水线是否能正常触发。甚至可以试着新建一个项目，验证一下写入权限是否正常，请大家务必...。

常见问题排查指南

虽然我们希望一切顺利，但现实往往充满变数。这里简单列举几个可能遇到的问题和应对思路， 火候不够。 希望能帮你在绝望中找到一丝光亮。

错误现象	可能原因	解决思路
恢复时提示版本不匹配	新旧服务器GitLab版本不一致。	使用 apt-get install gitlab-ce=版本号 降级或升级新服务器至一致版本。
登录后提示500错误或页面空白	通常是 gitlab-secrets.json 未恢复或权限不对。	检查 /etc/gitlab/ 下的密钥文件是否正确覆盖，并重启服务。
无法上传头像或附件	可能是 nginx 配置问题或目录权限。	检查 /var/opt/gitlab/gitlab-rails/uploads 目录权限。
CI/CD Pipeline 失败	Runner注册信息丢失或密钥变更。	重新注册Runner，或检查 gitlab-secrets.json 中包含的Runner secrets。

迁移只是新的开始

Ubuntu下的GitLab数据迁移， 说到底，就是一场关于细心和耐心的考验。从版本确认、备份创建、文件传输，到到头来的恢复与验证，每一个环节都扣人心弦。虽然过程中可能会遇到各种意想不到的“坑”， 但当你看到新服务器上平稳运行的GitLab，所有的疲惫都会烟消云散。

得了吧... 记住备份不仅仅是迁移时的需要，更应该成为日常运维的习惯。毕竟谁也不知道明天和意外哪个先来。希望这篇文章能成为你手中的利剑，助你在数据迁移的战场上披荆斩棘，轻松搞定每一次项目转移。现在去享受新服务器带来的流畅体验吧！

---