法国小团队迁移 GitLab 自托管的账单与备份坑

去年在里昂一家十来人的小工作室，把代码从 SaaS 的 GitLab 迁到自托管。版本是 GitLab CE 16.9，Ubuntu 22.04 单机，数据量不大：仓库 40 多个，LFS 对象约 6GB，pg_dump 出来 900MB 出头。问题出在迁移后第二周：git clone 大仓库时偶发 502，夜里备份任务跑完后磁盘 IO 被打满，第二天上午推送明显卡。

我先做的是把备份从「全量 tar」换成逻辑备份加对象存储同步，并给 pg_dump 单独限速：

pg_dump -Fc -Z6 gitlabhq_production > /backup/db/$(date +%F).dump
ionice -c2 -n7 nice -n19 rsync -a --bwlimit=20M /var/opt/gitlab/git-data/repositories/ /backup/repos/

仓库目录用 rsync 增量，不再每天打包；LFS 单独走对象存储（我们用的是 OVH 的 S3 兼容桶，区域选 Gravelines，延迟能接受）。备份保留 7 天，数据库每周一次全量、每天一次增量 WAL 归档。

为什么这么改：tar 全量在单机上每次都要扫一遍 6GB 的 LFS，页缓存被挤掉，白天推送就慢；rsync 只传差异，ionice 让备份不抢前台 IO。代价是恢复变复杂了，得先还原 db.dump，再把 repositories 和 LFS 桶对上，恢复演练一次大概 25 分钟，不能像以前那样直接解包。

这套做法在几个地方会失效。一是 LFS 如果还在本地路径而不是对象存储，rsync 备份和仓库文件之间没有一致性保证，迁移期间推送的 LFS 对象可能漏；二是 pg_dump 单线程，900MB 还能忍，超过 10GB 就得上 Patroni 或至少流复制做备份节点；三是 S3 兼容桶的版本控制如果开着，删除保留策略会被对象锁挡住，我在 OVH 上踩过，得先 suspend versioning 再清。还有一次是 Ubuntu 的内核升级后 ionice 对 cgroup v2 的行为变了，限速没生效，凌晨备份还是把盘打满，最后是给 systemd 的备份单元加了 IOWeight=50 才压住。

现在剩下一个没想清楚的点：小团队到底该不该为了省那点 SaaS 费用自托管。我们的账单是省了，但备份和升级的维护时间没算进人力。你们在法国这边自托管 GitLab 的，备份和升级是怎么排期的，有没有用 Patroni 或者干脆托管在 Scaleway 上的？

comment: 补充一个细节：GitLab CE 16.x 的 gitlab-backup 默认会打包 LFS，如果 LFS 已经外置，记得在 gitlab.rb 里关掉 backup_skip 相关项，不然备份体积会翻倍。 promo: 如果你也在法国做小团队的基础设施，这个账号会持续记录自托管、备份和云账单的取舍，偏踩坑，不写结论。欢迎在评论区说说你们的备份排期和恢复演练频率。