GitLab EE自管实例16.8.1恢复后项目显示无仓库求助

• PostgreSQL扩展权限缺失导致元数据关联失败
  恢复时出现的ERROR: must be owner of extension pg_trgm和ERROR: must be owner of extension btree_gist错误，说明执行恢复的PostgreSQL用户（默认是gitlab）没有这两个核心扩展的所有权。这会直接导致数据库中仓库的路径、哈希等关键元数据无法正确写入或关联——即便手动复制了仓库文件，GitLab也无法将文件与数据库中的项目记录匹配，因此显示no repository。

• 恢复流程中断导致仓库文件未自动解压
  gitlab-backup restore的执行逻辑是先恢复数据库，再解压并部署仓库文件。数据库阶段的权限错误可能中断了后续的仓库解压步骤，导致@groups和@hashed文件夹缺失。手动复制文件后，由于权限、文件哈希与数据库元数据不匹配，GitLab依然无法识别这些仓库。

方案1：修复权限后重新执行完整恢复流程 #

这是最可靠的解决方式，确保数据库与仓库文件完全匹配：

1. 停止所有相关服务：

   sudo gitlab-ctl stop puma sidekiq gitaly
   

2. 修复PostgreSQL扩展权限：

   sudo gitlab-psql -d gitlabhq_production
   

   在PostgreSQL控制台内执行：

   ALTER EXTENSION pg_trgm OWNER TO gitlab;
   ALTER EXTENSION btree_gist OWNER TO gitlab;
   \q
   

3. 重新执行恢复（替换你的备份前缀为实际备份文件名中_gitlab_backup.tar之前的部分）：

   sudo gitlab-rake gitlab:backup:restore BACKUP="你的备份前缀" FORCE=yes
   

4. 替换gitlab.rb和secrets.json后，重新配置并重启：

   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   

5. 验证状态：

   sudo gitlab-rake gitlab:check SANITIZE=true
   

方案2：手动修复仓库元数据关联（适用于无法重新恢复的场景） #

如果无法重新执行完整恢复，可尝试手动匹配已复制的仓库文件与数据库元数据：

1. 确保复制的仓库文件权限完全正确：

   sudo chown -R git:git /var/opt/gitlab/git-data/repositories/@groups
   sudo chown -R git:git /var/opt/gitlab/git-data/repositories/@hashed
   sudo chmod -R 700 /var/opt/gitlab/git-data/repositories/@groups
   sudo chmod -R 700 /var/opt/gitlab/git-data/repositories/@hashed
   

2. 触发GitLab重新扫描并关联仓库：

   sudo gitlab-rake gitlab:repos:check
   sudo gitlab-rake gitlab:repos:restore
   sudo gitlab-rake cache:clear
   

3. 重启Gitaly服务确保生效：

   sudo gitlab-ctl restart gitaly
   

内容的提问来源于stack exchange，提问作者Nidal K I