做GitLab运维这些年，备份恢复和迁移这摊子事我踩过的坑比很多教程写过的字都多。标题里这几个词看着简单，真到了线上环境实操，全是细节活。这篇东西我不打算讲那些官网文档里已经写清楚的基础用法，而是把我实际跑过的备份恢复流程、迁移方案，以及那些文档里不会明说但能救命的关键点，一次性梳理出来。

先说个大概：GitLab本身的结构决定了它跟普通应用不太一样，代码数据、数据库、配置文件、密钥文件、对象存储、CI/CD缓存，分散在系统的各个角落。很多人备份时只跑了一条命令就把备份文件拷走了，等真出事故要恢复，才发现要么缺了密钥导致恢复出来全是乱码，要么配置没备份导致服务起不来。这篇文章要解决的，就是这个“完整备份”的问题。

无论你是刚搭好GitLab准备做第一次备份的运维新人，还是已经在跑生产环境、正打算从旧服务器迁到新机器或者从物理机迁到Docker环境的老手，下面这套流程都可以直接照着操作。我会把每一步“为什么这么做”讲透，而不是只丢给你一串命令。

1. 备份方案的整体思路与设计考量

1.1 搞清楚GitLab到底有哪些东西需要备份

很多人在这一步就栽了。GitLab不是单一进程，它是由多个组件协同工作的系统：底层是Rails应用，数据存储在PostgreSQL数据库里，代码仓库本身在文件系统上，另外还带着Redis、GitLab Shell、Gitaly存储服务，以及可选的对象存储、容器镜像仓库。所以备份方案设计的第一步，是列清楚备份对象的清单，缺一个都不行。

我在给团队做备份方案时，会明确划分成四类必须备份的内容：

• 配置文件：/etc/gitlab/gitlab.rb和/etc/gitlab/gitlab-secrets.json，前者是全部配置的入口，后者是各类服务加密密钥。
• 数据库数据：存在于PostgreSQL里，用官方工具备份时会被自动包含。
• 仓库数据：所有代码仓库的文件，默认路径在/var/opt/gitlab/git-data/repositories。
• 附加数据：包括CI/CD日志、Runner注册token、容器镜像仓库数据、S3对象存储内容，以及部分自定义上传文件。

这套分类逻辑直接决定了我接下来备份命令怎么敲。官方工具gitlab-backup能一次性覆盖数据库和仓库，但配置文件和密钥文件必须单独手动备份。这个区别，稍后实际执行时能看到明显体现。

1.2 为什么推荐官方备份工具而不是直接拷贝目录

有人图省事，直接用cp -r或tar把/var/opt/gitlab整个目录打包带走，我见过这么干的人不在少数。这里要泼一盆冷水：GitLab正在运行时，数据库和仓库文件时刻处于写状态，直接拷贝文件得到的是一个不一致的快照。数据库可能拷到一半被截断，仓库目录里的文件状态也没法保证是同一个时间点的，这种备份别说恢复，连校验都过不了。

正确姿势是用GitLab自带的工具gitlab-backup。它内部会做几件关键的事：先冷备份数据库，保证PostgreSQL的VACUUM和WAL日志状态一致；再通过tar对仓库目录做一致性打包；最后生成一个带时间戳的tar包，放在配置指定的备份目录里。这套机制能保证备份出来的数据在逻辑上是完整的。

还有一个容易忽略的点，备份文件本身默认存在本地磁盘，也就是/var/opt/gitlab/backups。如果服务器本身挂了，备份跟着一起消失，等于白备份。所以备份方案里我一定会再加上“异地/对象存储同步”，把备份文件定时推到另外的机器或者S3兼容存储上。实际操作中我的策略是“本地留一份最近3天的，远程留30天的”，这样兼顾快速恢复和历史回溯。

1.3 备份策略设计：全量加增量的取舍

官方备份工具只做全量备份，没有原生增量能力。很多人觉得全量太重，想自己做增量，我的建议是别折腾。GitLab仓库数据压缩率其实不错，一个2GB的代码库，用官方工具打包完也就几百MB。只要GitLab本身不是千级仓库的巨无霸，全量备份的磁盘消耗完全在可接受范围内。

真到了仓库量极大、全量备份时间拉长的阶段，也优先考虑“提高备份频率+拉长生命周期”，而不是自己造增量工具。我在一个仓库总数超过3000个的实例上跑过，全量备份一次大约15分钟，一天两次完全扛得住。核心原因在于git-backup本身对仓库有引用计数和增量克隆支持，但那是另一个复杂度层级，绝大多数团队用不上。

备份策略上我这边实际执行的计划是：每天凌晨2点一次全量，备份文件保留7天；每周一凌晨额外把当天的备份文件推送到对象存储，留12周；每月1日把当月归档保存一年。这样既控制磁盘成本，又能满足不同维度的恢复要求。简单说：你备份的是“某一个时刻整台GitLab的完整状态”，全量是最可靠且最省心的方式。

2. 核心备份实操：从零开始的完整备份过程

2.1 环境准备与版本确认

动手备份前，先确认GitLab版本，这一步在恢复和迁移时尤其关键。GitLab的备份文件与版本绑定非常严格，同主版本号内部修复版本迁移通常没问题，但跨大版本恢复极容易报错。所以备份前我习惯先跑一条命令：

sudo gitlab-rake gitlab:env:info

这个命令会把GitLab版本、组件版本、系统平台信息全部列出来。或者更简单：

sudo head -1 /opt/gitlab/version-manifest.txt

版本确认的目的不光是为了记录，还在恢复时帮你判断两边环境是否匹配。我在迁移方案里一直强调“目标机器要装同版本GitLab再恢复”，就是因为版本差异是恢复失败的最大来源。

接下来确认备份目录和权限。默认备份目录是/var/opt/gitlab/backups，如果改了gitlab.rb里gitlab_rails['backup_path']配置，就按你配置的路径来。检查这个目录的属主和权限，确保GitLab用户有写权限：

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

2.2 配置文件备份：很多人漏掉的关键一步

我一直强调，配置文件备份和数据备份是两套完全独立的事。数据备份靠gitlab-backup命令，配置文件靠最直接的复制。至少需要备份两个文件：

• /etc/gitlab/gitlab.rb：全部自定义配置，包括域名、端口、外部URL、数据库密码、备份设置、对象存储配置等。
• /etc/gitlab/gitlab-secrets.json：GitLab各类服务的加密密钥，包括数据库加密密钥、OAuth密钥、CI/CD密钥、双因子认证密钥。

为什么gitlab-secrets.json这么重要？GitLab里很多数据在写入数据库时就用这个文件里的密钥做了加密，比如CI/CD的变量值、用户的2FA密钥、Webhook的token。恢复数据库时如果没有对应的密钥文件，这些密文将无法解密，轻则报错，重则用户无法登录。我在迁移时遇到过一整批CI/CD变量恢复后全部变成无效值的情况，根因就是secrets文件没同步。

正确做法是备份时把这两个文件打包到一个独立路径：

sudo mkdir -p /var/opt/gitlab/config-backup sudo tar czf /var/opt/gitlab/config-backup/etc-gitlab-$(date +%F-%H%M).tar.gz /etc/gitlab/

每次备份都同时生成一份配置归档，方便在恢复时把时间点对齐。

2.3 执行GitLab数据全量备份

配置文件搞定后，数据备份就是一条命令的事。GitLab 12.x 以上版本的格式是：

sudo gitlab-backup create

早期版本或者感受到命令不存在的，用旧命令：

sudo gitlab-rake gitlab:backup:create

执行过程中会看到类似这样的输出：

Dumping database ... Dumping repositories ... Dumping uploads ... Dumping builds ... Dumping artifacts ... Creating backup archive: 1700000000_2023_11_15_16.4.1_gitlab_backup.tar ...

等最后出现Backup task is done.就说明成功了。备份文件会落在/var/opt/gitlab/backups/目录下，命名规则是{时间戳}_{日期}_{版本}_gitlab_backup.tar。比如1700000000_2023_11_15_16.4.1_gitlab_backup.tar，里面包含了版本号，恢复时需要严格对照。

这里有个实用参数：如果你不想备份某一类数据，可以用SKIP跳过。比如不想备份CI/CD artifacts：

sudo gitlab-backup create SKIP=artifacts

但我个人建议，除非存储真的吃紧，否则别跳过任何一项。一旦恢复时发现某块数据缺失，再回去找备份就晚了。

2.4 备份文件的验证与异地存储

备份完成了不等于备份有效。我见过太多人跑了备份命令就以为万无一失，结果到要恢复的时候，发现备份包坏了或者内容不完整。更稳妥的做法是，每次备份完做一个基础验证：先看备份文件的体积是否正常，再检查tar包内部结构是否完整：

sudo tar -tf /var/opt/gitlab/backups/1700000000_2023_11_15_16.4.1_gitlab_backup.tar | head -20

如果tar包都解不出来，说明备份过程有问题，趁早排查。更进一步的做法是在测试环境上直接做一次恢复演练，这是后话，但强烈建议周期性执行。

异地存储这块，我用的是rsync加对象存储双通道。先本地保留，再同步到备份服务器：

rsync -avz /var/opt/gitlab/backups/ backup-server:/data/gitlab-backups/

如果配置了S3兼容存储，可以走GitLab自带的配置，在gitlab.rb里加上：

gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'us-east-1', 'aws_access_key_id' => 'xxxx', 'aws_secret_access_key' => 'xxxx' }

上传到云端后，备份的物理安全就基本有保障了。毕竟服务器机房进水、硬盘损坏这种极端情况虽然概率低，但一旦发生，没有异地备份就是灾难。

3. 恢复实操：从备份到服务可用的全过程

3.1 恢复前的检查清单

真正到了要恢复的时候，千万别上来就直接执行恢复命令。先用三分钟把这些重点确认一遍，能帮你避免在恢复过程中发现环境没法用：

• 确认GitLab版本与备份文件中的版本一致（至少主版本一致）。
• 确认备份文件存在且权限正常，没有损坏。
• 确认数据库类型一致（PostgreSQL主版本不能差太多）。
• 确认备份目录有足够空间，恢复时会先解压再导入，需要的临时空间大约是备份文件的两到三倍。
• 确认gitlab.rb和gitlab-secrets.json已经恢复到目标机器上。

尤其是secrets文件这一点，我再次强调，因为恢复报错“机密信息不一致”的频率太高了。GitLab在初始化安装时就会生成gitlab-secrets.json，如果目标机器是全新安装的，它已经有一个自己的密钥文件，这时直接把备份的secrets文件覆盖过去即可。

3.2 全新环境恢复GitLab的完整步骤

第一步，安装与备份版本一致的GitLab。用Omnibus包安装或者Docker方式都可以，核心是版本要匹配。

第二步，恢复配置文件。把自己备份的gitlab.rb和gitlab-secrets.json复制到对应位置：

sudo cp /backup/etc-gitlab/gitlab.rb /etc/gitlab/gitlab.rb sudo cp /backup/etc-gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json sudo chmod 600 /etc/gitlab/gitlab-secrets.json sudo gitlab-ctl reconfigure

这里reconfigure会很关键，它会把配置文件里的参数同步到各组件中。

第三步，把备份文件放到备份目录。注意备份文件属主要改成git用户：

sudo cp /path/to/1700000000_2023_11_15_16.4.1_gitlab_backup.tar /var/opt/gitlab/backups/ sudo chown git:git /var/opt/gitlab/backups/1700000000_2023_11_15_16.4.1_gitlab_backup.tar

第四步，执行恢复命令。GitLab 12.x以上用：

sudo gitlab-backup restore BACKUP=1700000000_2023_11_15_16.4.1

注意BACKUP参数要填写备份文件时间戳和版本号的前缀部分，不需要带_gitlab_backup.tar后缀。命令执行后会提示：

Before restoring the backup, we will remove all existing data...

这是GitLab在提醒你，恢复过程会清空当前所有数据。确认没问题后输入yes继续。

恢复过程中会依次解压数据库、仓库、上传文件等等。整个过程可能持续几分钟到几十分钟，取决于数据量。期间会看到很多warning，比如某个仓库连接超时之类，大部分是恢复过程正常的提示，但只要最后能看到Restore task is done.，基本就是成功了。

最后一步，重新配置并重启服务：

sudo gitlab-ctl reconfigure sudo gitlab-ctl restart

然后打开浏览器访问GitLab首页，用管理员账号登录，验证仓库、项目、用户、CI/CD配置都正常。

3.3 同环境恢复与只恢复部分数据

有些时候不需要恢复到全新环境，而是在当前服务器上把数据回滚到某个备份点。比如误删了一批代码，或者某次配置变更导致数据异常。这种同环境恢复的流程跟全新环境几乎一样，但要特别注意两点：

一是GitLab服务要处于运行状态，但最好先把不必要的流量切走，避免恢复期间有人写入新数据。恢复命令本身会锁库，但如果有人恰好在这个时间窗提交代码，恢复完这些提交就丢了。

二是如果需要恢复的只是少量仓库，不需要做全量恢复。可以直接从备份的tar包里单独解压对应仓库的裸仓库数据，放到repositories目录下。这个方法在很多应急场景里非常实用，我处理过几次误删仓库的求助，都是直接从备份包里解压单个仓库：

mkdir /tmp/gitlab-restore tar -xf /var/opt/gitlab/backups/1700000000_2023_11_15_16.4.1_gitlab_backup.tar -C /tmp/gitlab-restore ls /tmp/gitlab-restore/repositories/group/project.git

找到目标仓库的.git目录后，停掉GitLab，把文件复制回/var/opt/gitlab/git-data/repositories/group/project.git，设置好属主并执行gitlab-ctl start。这种方式不需要全量恢复，恢复速度快很多。

4. 迁移实操：跨服务器与跨版本迁移方案

4.1 迁移前的风险评估与方案选型

迁移和恢复本质上是一回事，都是把备份数据搬到目标机器上。但迁移有个额外的复杂度：源环境和目标环境往往不完全一致。可能源机器是老版本GitLab，目标要装新版本；可能源是物理机，目标是Docker容器或Kubernetes Pod；可能源是单实例，目标是高可用集群。

我在做迁移方案评估时，会把场景分成三类，针对每类选择不同的策略：

• 同版本、同环境迁移：直接用备份恢复，最稳妥。
• 跨大版本迁移：建议先升级源到目标版本，再迁移。或者先迁移到同版本，再在目标机器上升级。
• Docker或Kubernetes迁移：备份恢复流程基本一致，但容器数据卷的挂载和权限需要额外处理。

无论哪一类，迁移前都要先确认一件事：停机窗口能接受多久。GitLab的备份恢复不是零停机方案，备份期间数据虽然冻结了，但恢复期间服务是停止的。如果要求不停机迁移，那需要走GitLab官方推荐的另一种方案——基于仓库镜像的双写同步，这个复杂度非常高，一般团队用不到。如果你能接受1到2小时的停机窗口，备份恢复方案是最实际的。

4.2 同版本迁移：从旧服务器到新服务器的完整实操

假设现在要把一台跑着GitLab 16.4.1的旧服务器A，整体迁移到同为16.4.1的新服务器B。流程分四大步。

第一步，在A上做一次全量备份，同时备份配置文件和secrets文件：

sudo gitlab-backup create sudo tar czf /var/opt/gitlab/config-backup/etc-gitlab-$(date +%F-%H%M).tar.gz /etc/gitlab/

第二步，把备份文件传到B上。传输方式随意，scp、rsync都行：

rsync -avz /var/opt/gitlab/backups/xxx_gitlab_backup.tar user@B:/tmp/ rsync -avz /var/opt/gitlab/config-backup/etc-gitlab-xxx.tar.gz user@B:/tmp/

第三步，在B上安装相同版本的GitLab。安装完成后，先恢复配置文件：

sudo tar -xzf /tmp/etc-gitlab-xxx.tar.gz -C / sudo gitlab-ctl reconfigure

这一步非常关键，一定要在恢复数据之前做。先让GitLab按旧配置启动起来，把基础组件初始化好，再接数据。

第四步，恢复数据：

sudo cp /tmp/xxx_gitlab_backup.tar /var/opt/gitlab/backups/ sudo chown git:git /var/opt/gitlab/backups/xxx_gitlab_backup.tar sudo gitlab-backup restore BACKUP=xxx sudo gitlab-ctl reconfigure sudo gitlab-ctl restart

迁移完成后，第一时间要验证域名是否正常访问，仓库能否克隆，CI/CD runner是否重新注册，用户是否能登录。尤其要注意Runner的注册需要重新关联，因为Runner token存在数据库里，恢复后没问题，但Runner本身不一定能自动连上AI，需要手动检查。

4.3 跨版本迁移：低版本到高版本的正确姿势

跨版本迁移是踩坑重灾区。很多人的习惯是：旧服务器是15.x，直接装一台16.4.1的新服务器，然后把15.x的备份直接恢复进去。结果大概率报错，提示备份版本不兼容。

GitLab官方对跨版本升级有明确的路径要求，必须逐主版本升级，不能跳版本。比如从15.4升到16.4，正确路径是：15.4 → 15.11 → 16.0 → 16.4。对应到迁移上，我一般推荐两种方案：

方案一（推荐）：在旧机器上先按官方升级路径把GitLab升到目标版本，然后再做备份迁移。这种方式的好处是升级过程中GitLab自己会做数据迁移和schema更新，备份出来的数据已经是最新的格式，到新机器直接恢复就行。

方案二：先迁移再升级。先在B上装和A相同版本的GitLab，恢复备份确认一切正常，然后在B上升级。这个方案的好处是升级出问题不会影响原机器，坏处是B要从旧版本一路升上来，耗时可能较长。

无论哪种方案，跨版本后都要做一次深度验证，重点检查：仓库Web界面能否正常展示history、merge request数据是否完整、CI/CD pipeline历史记录是否还在、集成应用（如Slack、Jira）的token是否失效。

4.4 Docker环境迁移：容器数据卷与备份恢复的特殊处理

Docker部署GitLab已经很普遍了，我自己也维护过几个容器化实例。容器化迁移和物理机迁移最大的区别在于：容器本身是个可丢弃的状态，真正要迁移的是挂在宿主机上的数据卷。

常见的Docker GitLab部署命令：

docker run --detach \ --hostname gitlab.example.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ gitlab/gitlab-ee:16.4.1

看到没有，config、logs、data三个目录都挂载在宿主机上。容器迁移实际上就是把这三个目录搬到新宿主机，再重新启动一个容器。

具体操作分三步：

第一步，在旧容器内执行备份命令：

docker exec -t gitlab gitlab-backup create

第二步，把三个挂载目录整体打包传到新宿主机。这里有个细节：目标是直接把整个数据卷复制过去，所以连配置文件都不用单独处理：

tar czf gitlab-config.tar.gz $GITLAB_HOME/config tar czf gitlab-data.tar.gz $GITLAB_HOME/data

第三步，在新宿主机上解压到相同的目录结构，然后启动容器：

mkdir -p $GITLAB_HOME tar -xzf gitlab-config.tar.gz -C $GITLAB_HOME/ tar -xzf gitlab-data.tar.gz -C $GITLAB_HOME/ docker run --detach ... (同样的启动命令)

启动完成后，因为config和data目录都在，GitLab会自动按原配置工作。这个方式的优点是避免了备份恢复的版本匹配问题，缺点是数据卷必须跟容器版本匹配。如果你要换镜像版本，还是得走标准备份恢复流程。

5. 常见问题与排查技巧实录

5.1 恢复时报错：备份文件版本不匹配

这是恢复过程中最常见的错误。报错内容类似：

GitLab version mismatch. You are trying to restore a backup which was created with GitLab 16.4.1. You are currently running GitLab 16.0.0.

原因就是目标环境版本和备份版本不一致。解决办法没有捷径，要么把目标环境升级到备份版本，要么用对应版本的备份文件。如果备份文件和GitLab版本差一个主版本以上，别硬来，按官方升级路径先升级目标环境。

我自己的习惯是，每次升级GitLab后都会做一次全量备份，并且把旧版本的备份文件额外留一份。这样万一升级后发现新版本有严重bug，还能回退到旧版本的数据。

5.2 GitLab服务起不来的排查思路

恢复数据或者迁移后，遇到最多的是服务启动失败。可能原因有好几类，排查时要一步一来：

第一，查看服务状态：

sudo gitlab-ctl status

第二，查看错误日志：

sudo gitlab-ctl tail

第三，确认端口是否被占用：

sudo lsof -i :80

第四，确认数据目录权限是否正常。

最常见的启动失败原因是/var/opt/gitlab目录的属主不对。有时候用root复制备份目录会导致归属变成root，GitLab进程没权限访问。解决方式：

sudo chown -R git:git /var/opt/gitlab sudo gitlab-ctl restart

另一个高频问题出现在数据库无法连接，通常是因为gitlab.rb里改了数据库密码，但reconfigure没有被执行或执行失败。恢复后一定要跑一遍sudo gitlab-ctl reconfigure，它会把配置里的密码同步到PostgreSQL配置文件中。

5.3 用户登录失败或双因子认证失效

这个问题的根因基本就是gitlab-secrets.json没同步。GitLab用这个文件里的密钥加密用户的双因子认证信息以及CI/CD变量，如果密钥不匹配，恢复后的数据库里存着的是旧机器加密过的密文，新机器用自己的密钥解密不了。

解决方式：确认恢复前已经把原机器的gitlab-secrets.json复制到目标机器的/etc/gitlab/下，然后执行：

sudo gitlab-ctl reconfigure sudo gitlab-ctl restart

如果gitlab-secrets.json丢了，那就麻烦大了。数据库里大量加密数据将不可逆地损坏，用户的双因子认证需要逐个重置，CI/CD变量会失效，Webhook密钥作废。所以备份时，这个文件怎么强调都不为过。

5.4 备份目录空间不够的应对方法

备份执行到一半报错No space left on device的情况也很常见。GitLab备份过程会先生成临时文件，再合并成tar包，临时空间大约等于备份目标文件的1到2倍。备份目录空间不足，最简单的处理是换一个空间充足的目录，在gitlab.rb里修改：

gitlab_rails['backup_path'] = '/data/gitlab-backups'

改完执行sudo gitlab-ctl reconfigure。如果目标机器上数据盘挂在/data，这个配置还挺合理的。再把已有的备份文件同步过去，继续后续操作。

如果只是临时解决一次备份，也可以给备份目录做一个软链接指向大容量磁盘，这样不用改配置：

sudo mv /var/opt/gitlab/backups /data/gitlab-backups sudo ln -s /data/gitlab-backups /var/opt/gitlab/backups

5.5 备份恢复后仓库为空或者看不到项目

这个问题的排查思路需要先判断是“数据没恢复”还是“权限没恢复”。先用管理员账号登录，去看管理后台里的项目列表。如果项目列表是空的，说明数据库恢复不完整，大概率是备份文件本身就没包含这部分数据，或者恢复时数据库导入失败了。

如果项目列表有项目，但普通用户看不到，那就不是数据问题，是权限配置问题。GitLab的group和project权限存在数据库里，恢复时应该一起过来。有时候因为版本差异导致权限表结构有变化，会出现权限丢失的情况。处理方式是用管理员账号重新配置项目可见性，或者重置成员权限。

我遇到过一种比较刁钻的情况：仓库文件恢复了，但在Web界面上看不到任何提交记录。排查后发现在全量备份时，仓库的HEAD指针文件丢失。这种就只能从备份tar包里手动解压对应仓库，检查git log的完整性和refs目录，必要时用git fsck修复。

6. 备份文件的自动化与周期性维护

手工备份做一次容易，坚持做却很难。我见过不少团队，买服务器时装了GitLab，做了一次备份再也没管过，到几个月后真的出事才想起来。所以这里强烈建议把备份做成定时任务。

用cron最简单直接：

0 2 * * * /usr/bin/gitlab-backup create >> /var/log/gitlab-backup.log 2>&1 0 3 * * * /usr/bin/find /var/opt/gitlab/backups -type f -mtime +7 -delete

第一行每天凌晨两点执行全量备份，第二行清理7天前的备份文件。也可以融合对象存储上传：

30 2 * * * rclone copy /var/opt/gitlab/backups/ remote:gitlab-backups/

整个自动化体系里，最难维护的其实是备份后的恢复演练。我的经验是至少每季度挑一个低峰期，在新的测试服务器上完整恢复一次备份，确认数据可用性。这样既验证了备份文件本身没有损坏，也让团队里的每个人都能熟悉恢复流程，真出故障时不至于手忙脚乱。

如果说备份是全自动跑出来的，那恢复能力一定是练出来的。备份做得好，只是在硬盘上留下了一堆文件；恢复做得熟，才是在脑子里刻下了一条可行的逃生路线。这两件事缺一不可。

我个人在实际操作中体会到的一点是，GitLab备份恢复迁移这套流程，前期多花半小时确认版本、配置和secrets文件，后面就能少熬几个通宵。每次出问题，九成以上都能追溯到这三个基础项上。至于那些五花八门的报错信息，别慌，先对照这篇文章里的排查思路走一遍，多数都能找到方向。真到了搞不定的地步，GitLab官方文档和社区issue里的信息也非常全，把日志贴上去搜，基本都能找到答案。