在生产环境中，如果 部署在阿里云服务器上的 GitLab 突然磁盘占用 100%，会导致：
-
GitLab 页面无法访问
-
无法 push / pull 代码
-
CI/CD 任务失败
-
服务器甚至无法登录
这时候必须 第一时间抢修磁盘空间。本文记录一次真实的 GitLab 抢修过程，5分钟恢复服务。
一、先确认磁盘是否真的满了
登录服务器执行：
df -h
输出类似：
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 40G 0 100% /
如果看到 Use% = 100%，说明磁盘已经爆满。
二、快速定位是哪个目录占满空间
执行：
du -h –max-depth=1 /
重点关注：
/var
/home
/opt
一般 GitLab 会安装在：
/var/opt/gitlab
继续查看：
du -h –max-depth=1 /var/opt/gitlab
常见占用：
repositories
gitlab-rails
backups
log
三、GitLab 最常见的磁盘爆满原因
GitLab 磁盘爆满通常是以下几个原因：
| gitlab/backups | 自动备份过多 |
| gitlab-rails/shared/artifacts | CI 产物 |
| gitlab-rails/shared/lfs-objects | LFS 大文件 |
| log | 日志爆炸 |
| repositories | 仓库体积过大 |
四、最快的抢救方案（立刻释放空间）
1 删除 GitLab 旧备份
GitLab 默认备份路径：
/var/opt/gitlab/backups
查看：
ls -lh /var/opt/gitlab/backups
删除旧备份：
rm -rf /var/opt/gitlab/backups/*
⚠ 注意：
如果没有重要备份，可以直接删除。
2 清理 GitLab 日志
日志可能占几个 G。
du -sh /var/log/gitlab
清理：
gitlab-ctl truncate-logs
或者：
rm -rf /var/log/gitlab/*
3 清理 CI 产物
CI 产物路径：
/var/opt/gitlab/gitlab-rails/shared/artifacts
查看：
du -sh /var/opt/gitlab/gitlab-rails/shared/artifacts
删除：
rm -rf /var/opt/gitlab/gitlab-rails/shared/artifacts/*
五、清理 Docker（很多人忽略）
如果 GitLab Runner 使用 Docker，磁盘很可能被 Docker 占满。
查看：
docker system df
清理：
docker system prune -a
强制清理：
docker system prune -a -f
六、重新启动 GitLab
释放空间后执行：
gitlab-ctl restart
检查服务：
gitlab-ctl status
七、预防磁盘再次爆满（我自己有设置确实很好用，能扩容出30%的兜底）
1 设置 GitLab 备份保留策略
编辑配置：
vim /etc/gitlab/gitlab.rb
增加：
gitlab_rails['backup_keep_time'] = 604800
表示：只保留7天备份
生效：
gitlab-ctl reconfigure
2 设置日志自动清理
执行：
gitlab-ctl tail
查看日志增长情况，推荐开启 logrotate。
3 定期清理 Docker
定时任务：
crontab -e
添加：每天凌晨清理。
0 3 * * * docker system prune -af
八、一条命令快速找出最大目录
本人最喜欢的常用命令：查看最大目录。
du -sh /* | sort -hr
最后总结一下：
GitLab 磁盘 100% 在生产环境其实是非常常见的问题，大多数情况下都是由于 备份文件、CI 产物、日志文件或 Docker 镜像堆积导致的。
只要按照本文的排查思路：
使用 df -h 确认磁盘使用情况
使用 du -h 定位占用空间的目录
清理 GitLab backups、logs、artifacts
必要时清理 Docker 镜像和容器
基本都可以在 几分钟内恢复 GitLab 服务。
生产环境中建议提前做好 日志轮转、备份保留策略以及磁盘监控，避免类似问题再次发生。
如果这篇文章对你有帮助，欢迎 点赞 、收藏 、评论交流，也欢迎分享你的 GitLab 运维经验。
