这两天的经历，像被命运按在地上来回摩擦，又像被塞了一张速成运维结业证。
故事从一台外网 GitLab 开始。公司内外网物理隔离，出差的同事总得有个地方提交代码，我便在外网搭了一台轻量级 GitLab——Docker 版，省事。用的人不多，备份服务器的申请流程就被我无限期搁置。事实证明，最薄弱的环节往往最先爆炸。
周末，一场突如其来的断电，让这台服务器当场“失联”。我冲进机房，接上显示器，只见启动读条慢得像 56 K 拨号，最终停在救援模式。CentOS 的救援 shell 于我如天书，研发同事、IT 同事轮番上阵，最终把研发经理请来。结论：文件系统损坏，/home 挂载失败；进一步扫描，磁盘出现坏道。万幸，GitLab 的数据目录不在 /home，所有文件被完整拷出——这是不幸中的万幸。
文件到手，能否原地复活 Docker 版 GitLab？运维同事给了肯定的眼神。我立刻申请公司云资源，开启 48 小时的“数据迁移生死时速”。
1. 新虚机装 Docker 与 docker-compose；
2. 拉取官方 GitLab 镜像；
3. 把备份文件一股脑上传；
4. 改 docker-compose.yml，指向新路径；
5. `docker-compose up -d`——容器秒退。
排查：防火墙、SELinux 已关，仍报错。把日志扔给 AI，答案瞬间浮现——宿主机挂载目录与容器内默认用户 UID 不一致。GitLab 容器里跑的是 UID 1000，而宿主机目录还是 root 的 0:0。
一行命令解决：
```bash
# 修改所有权（GitLab 容器内默认用户 UID=1000）
sudo chown -R 1000:1000 /data/gitlab
```
顺手再赋 755 权限，重新 `up`，绿色指示灯亮起——GitLab 在云端涅槃重生。
断电、坏盘、救援、迁移、排错，每一步都让人心跳爆表，也把“备份”二字烙进骨髓。下一步：写复盘、做备份、上监控，再也不敢裸奔。