GitLab CE：如何恢复或修复突然丢失的问题/合并请求的存储库？

Question

大约两年前，我开始在本地 x86 Debian VM 内运行 GitLab CE，去年我决定将 GitLab CE 实例迁移到专用的 Intel NUC 服务器。一切似乎都很顺利，没有任何问题，并且我的 GitLab CE 实例截至今天是最新的（运行 13.4.2）。

但我最近发现，一些被移动的存储库给出了“没有存储库！” 访问他们的项目页面时出错，如果他们有任何问题板、合并请求等，这些也都消失了。但您不会怀疑它，因为损坏的存储库与我一直使用的工作存储库一起出现在存储库列表中。

如果我必须对这些损坏的存储库进行推理，那就是它们在一年前进行了最后一次活动，除了初始推送之外，没有对它们进行任何推送，或者是否进行了更改、创建了问题或合并请求创建，它实际上是一年多前。

其中一些损坏的存储库相当大，有很多历史记录，而其他存储库则非常小（实际上只是跟踪 shell 脚本的更改），所以我认为存储库大小本身与此没有任何关系。

如果我运行 GitLab 诊断检查sudo gitlab-rake gitlab:check，除了“散列存储”之外，一切看起来都很好：

All projects are in hashed storage? ... no
  Try fixing it:
  Please migrate all projects to hashed storage

但随后运行sudo gitlab-rake gitlab:storage:migrate_to_hashed似乎没有完成（仪表板中有六个失败的作业），并且再次运行“gitlab：check”仍然表明存在“散列存储”问题。我也尝试过运行sudo gitlab-rake gitlab:git:fsck，sudo gitlab-rake cache:clear但这些命令似乎没有什么区别。

幸运的是，我的机器上有所有缺少的存储库的最新版本，事实上，我仍然有运行 GitLab CE 12.8.5 的原始虚拟机（存储库的副本稍微过时了。）

所以我的问题是：

1. 是否可以“修复”我当前实例上损坏的存储库？我怀疑我可以将这些存储库的本地副本“重新推送”回我的服务器，但我真的不想丢失任何元数据，例如问题/合并请求等。
2. 有没有办法解决“并非所有项目都在哈希存储中”的问题？（migrate_to_hashed任务再次未能完成。）
3. 我是否能够执行“备份”、“检查/调整备份”、“恢复备份”之类的操作来修复损坏的存储库，或者至少修复元数据？

提前致谢。

Answer 1

好的，所以我想我知道发生了什么。

我在GitLab 用户论坛上找到了这个帖子。

显然这里的场景是：

1. 有一个 GitLab 实例，其存储库不在“哈希存储”中
2. 备份您的存储库
3. 恢复您的存储库（恢复到同一服务器或迁移到另一服务器）
4. 自动或手动尝试将您的存储库更新为“哈希存储”
5. 现在，您会发现任何带有“ci runner”（持续集成运行程序）的存储库现在都将被列为“NO REPOSITORY！” 并且完全不可用，因为“散列存储”迁移过程将会失败

解决方法是：

1. 重置运行者注册令牌，如GitLab 文档中的本文所列
2. 重新运行该sudo gitlab-rake gitlab:storage:migrate_to_hashed过程
3. 后台作业完成后，运行sudo gitlab-rake gitlab:check以确保输出包含以下消息：

All projects are in hashed storage? ... yes

如果成功，项目将显示“NO REPOSITORY！” 现在应该已完全恢复。

了解是否需要运行此过程的关键是您是否：

1. 以管理员身份登录到您的 GitLab CE 实例
2. 前往管理区
3. 查看监控->后台作业->死亡
4. 并查看名为的工作

hashed_storage:hashed_storage_project_migrate

与错误

OpenSSL::Cipher::CipherError: