git_lab_事故恢复全过程（ubuntu_22

GitLab 事故恢复全过程（Ubuntu 22.04）

事故主题：SSH 删除并重新安装后，GitLab 无法使用

系统环境：Ubuntu 22.04

最终结果：成功恢复 GitLab 16 + PostgreSQL 14，数据完整

一、事故起因（历史记录第一条）

1.1 初始问题

在 Ubuntu 22.04 系统中，因 SSH 相关组件被删除并重新安装，随后发现：

GitLab Web 无法访问
GitLab 服务状态异常
Git 推送 / 拉取失败

用户初始疑问：

SSH 删除重新下载后发现 GitLab 无法使用，Ubuntu 22.04 如何恢复 GitLab？

二、系统初始状态确认

2.1 操作系统

Ubuntu 22.04 LTS

2.2 GitLab 安装形态

GitLab CE（Omnibus 安装）
数据目录：/var/opt/gitlab
配置目录：/etc/gitlab

三、问题表现（症状）

3.1 GitLab 服务异常

bash 复制代码

sudo gitlab-ctl status

多数服务处于 down 状态
PostgreSQL 无法启动
Puma / Sidekiq 未运行

3.2 数据库连接失败

bash 复制代码

sudo gitlab-rake gitlab:env:info

报错核心信息：

ActiveRecord::DatabaseConnectionError
connection to server ... failed
PostgreSQL socket 文件不存在

四、错误操作与干扰因素（重要）

在排查过程中，出现了以下高风险操作与干扰项：

误触 GitLab 自动升级
- 实际系统被升级到 GitLab 18
- Embedded PostgreSQL 版本升级到 16.x
历史数据仍为 PostgreSQL 14

bash 复制代码

cat /var/opt/gitlab/postgresql/data/PG_VERSION
# 输出：14

版本不匹配导致：

PostgreSQL 无法启动
gitlab-ctl pg-upgrade 失败
Rails migration 无法执行

五、关键判断（转折点）

5.1 真实数据状态

bash 复制代码

sudo head -n 1 /var/opt/gitlab/postgresql/data/PG_VERSION
# 14

bash 复制代码

/opt/gitlab/embedded/bin/postgres --version
# PostgreSQL 16.x

结论：

👉 数据是 PostgreSQL 14

👉 程序已升级为 GitLab 18 + PostgreSQL 16

👉 必须回退 GitLab，而不是升级数据

六、最安全的恢复策略

核心原则

不 initdb
不强制 pg_upgrade
保留原始 /var/opt/gitlab 数据
恢复 GitLab 16 + PostgreSQL 14 组合

七、恢复实施过程

7.1 停止所有 GitLab 服务

bash 复制代码

sudo gitlab-ctl stop

7.2 备份当前异常目录

bash 复制代码

sudo mv /var/opt/gitlab /var/opt/gitlab_current_$(date +%F)

7.3 恢复历史备份数据

bash 复制代码

sudo mkdir -p /var/opt/gitlab
sudo cp -a /var/opt/gitlab_backup_2026-02-06/* /var/opt/gitlab/

确认 PostgreSQL 数据版本：

bash 复制代码

cat /var/opt/gitlab/postgresql/data/PG_VERSION
# 14

八、第二个致命问题：磁盘空间耗尽

8.1 reconfigure 失败现象

text 复制代码

Errno::ENOSPC: No space left on device
/tmp/prometheus-mmapXXXX

8.2 排查磁盘

bash 复制代码

df -h

结果：

/ 根分区 100% 使用
/tmp 位于根分区，无法创建 mmap 文件

九、最终修复动作

9.1 清理空间 / 释放 /tmp

删除无用文件
清理历史缓存
确保根分区可写

9.2 重新执行配置

bash 复制代码

sudo gitlab-ctl reconfigure

结果：

Rails migration 成功
Prometheus 初始化成功
所有服务生成配置

9.3 重启 GitLab

bash 复制代码

sudo gitlab-ctl restart

十、最终验证

10.1 PostgreSQL 版本

bash 复制代码

sudo gitlab-psql -c "SELECT version();"

输出：

text 复制代码

PostgreSQL 14.11

10.2 GitLab 服务状态

bash 复制代码

sudo gitlab-ctl status

所有核心服务 run
GitLab Web 可访问
仓库、Issue、CI 数据完整

十一、根因总结（Root Cause）

直接原因

SSH 相关操作触发系统环境变化
GitLab 被误升级到 18

间接原因

GitLab 版本与 PostgreSQL 数据版本不匹配
根分区磁盘满，导致 /tmp 不可写

根因链路

text 复制代码

SSH 操作
 → GitLab 环境异常
 → GitLab 被升级到 18
 → PostgreSQL 版本不匹配
 → Rails migration 失败
 → 根分区满
 → GitLab 全部服务不可用

十二、最终结论

本次事故的本质不是 GitLab 或 PostgreSQL 损坏，而是版本错配 + 磁盘耗尽引发的级联故障。

通过：

回退 GitLab 至 16
保留 PostgreSQL 14 数据
清理根分区空间

👉 GitLab 成功完整恢复。

十三、可复用经验

永远先看 df -h
GitLab ≠ 可随意升级
PostgreSQL 数据版本优先级高于程序
/tmp 对 GitLab 至关重要

文档结束