这篇文章整理一下GitLab数据恢复时的一些常见问题对应方法。

环境与版本
容器化方式部署、运行在Kubernetes中
版本：GitLab-CE 12.10.5

数据卷挂载
gitlab的数据文件分成如下三类，使用容器化方式，一般会做成本地卷，则对此卷进行归档操作（比如tar命令）即可进行备份。

备份目录 说明
/var/log/gitlab 日志文件
/etc/gitlab 设定文件
/var/opt/gitlab 数据文件
恢复方式
恢复方式1:全卷使用
上述三个卷全部使用，重做GitLab容器，重启服务，理论上来说应该跟之前完全一致，在重启不能解决问题的时候，首先应该使用此种方式。

风险：如果有手动在容器中修改内容，但是此部分内容有未使用持久化的方式挂载出来的情况，则会存在风险，建议事前备份，容器启动不起来时，还是有些操作可以绕行的。更建议的是 基础框架即代码的方式，不要手工修改，所有操作应该以代码或者数据的方式存在，后续恢复自然简单地多。

恢复方式2: 不使用日志卷
GitLab容器启动之后，使用ps -ef 或者gitlab-ctl status就会知道，其实它启动了很多的进程，日志卷中保存此部分应用相关的数据和中间状态（出错的时候很多可能参照性却不强），如果方式1不能重启，首先考虑不使用日志卷进行恢复，此部分内容基本上不会对持久化数据产生影响

风险：同样存在手动在容器修改产生的问题，同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志，此部分内容需要进行评估。

恢复方式3: 使用reconfigure
使用方式1或者方式2仍然不能恢复的情况之下，考虑使用gitlab-ctl reconfigure命令重新恢复设定，相当于基于配置卷的内容进行恢复出厂设定，然后再使用gitlab-ctl restart重启服务，并通过gitlab-ctl status确认状态。

风险：此种方式也是具有一定风险，需要事先评估，尽可能的事前先将/etc/gitlab设定卷下的文件以及数据卷的内容进行保存，尤其是gitlab.rb，很多手工设定可能都在此文件之中，请注意这个过程中可能会更新/var/opt/gitlab下的各组件的设定内容，如果此部分有手工设定也会存在问题。同样存在手动在容器修改产生的问题，同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志，此部分内容需要进行评估。

恢复方式4: 仅使用数据卷
前面的方式反复执行均不可恢复的情况下，可继续尝试仅使用数据卷进行启动，基本上的数据是能够得到保证的，具体可以使用如下具体步骤：

步骤1: 进入容器之中
容器不能直接启动，但是还是有很多方式可以进入，比如启动时替换相应的命令等。

步骤2: 执行reconfigure
执行命令：gitlab-ctl reconfigure

注：此部容易出现错误执行不下去的情况，因为多少此GitLab的Chef脚本考虑到了一定的幂等性，可以多试几次，结合对于其下的数据进行删除，比如相关的prometheus或者redis的目录，在没有其他办法的情况下，在备份的基础上，可进行删除重试，因为reconfigure会重构这些文件。

步骤3: 重启gitlab服务
执行命令：gitlab-ctl restart

步骤4: 确认进程状态
执行命令：gitlab-ctl status

风险：此种方式也是具有一定风险，设定卷中很多内容尽可能的事前先将/etc/gitlab设定卷下的文件进行保存，尤其是gitlab.rb，很多手工设定可能都在此文件之中。同样存在手动在容器修改产生的问题，同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志，此部分内容需要进行评估。

常见问题
问题的现象虽然相同，但是实际的原因和对应方式可能不同，这里列出一些曾经出现过的问题和相应的解决方式予以参考。

问题示例1
部分日志和现象描述
There was an error running gitlab-ctl reconfigure:

runit_service[redis] (redis::enable line 66) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[restart_log_service] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/runit/libraries/provider_runit_service.rb line 69) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
STDOUT: timeout: down: /opt/gitlab/service/redis/log: 0s, normally up, want up
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log returned 1

— Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
STDOUT: timeout: down: /opt/gitlab/service/redis/log: 1s, normally up, want up
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log returned 1

Running handlers complete
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
解决方式
恢复方式1未能解决，使用到恢复方式2时解决。
问题示例2
部分日志和现象描述
最终出错的地方显示如下信息：

There was an error running gitlab-ctl reconfigure:

runit_service[prometheus] (monitoring::prometheus line 86) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus ----
STDOUT: timeout: run: /opt/gitlab/service/prometheus: (pid 710) 60s, got TERM
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus returned 1

Running handlers complete
1
2
3
4
5
6
7
8
9
10
但在之前出现了如下的错误信息

[0m * postgresql_user[gitlab] action create
* execute[create gitlab postgresql user] action run
[execute] psql: FATAL: the database system is starting up
[execute] psql: FATAL: the database system is starting up
[execute] psql: FATAL: the database system is starting up
1
2
3
4
5
解决方式
使用恢复方式4，手动删除prometheus和redis的目录，反复reconfigure和restart，最终成功
问题示例3
部分日志和现象描述
status显示redis的进程为 got TERM

gitlab-ctl status

run: alertmanager: (pid 30284) 52s; run: log: (pid 494) 10376s
run: gitaly: (pid 30298) 51s; run: log: (pid 492) 10376s
run: gitlab-monitor: (pid 30312) 51s; run: log: (pid 485) 10376s
run: gitlab-workhorse: (pid 30329) 50s; run: log: (pid 490) 10376s
run: logrotate: (pid 30344) 50s; run: log: (pid 486) 10376s
run: nginx: (pid 30350) 49s; run: log: (pid 487) 10376s
run: node-exporter: (pid 30358) 49s; run: log: (pid 483) 10376s
run: postgres-exporter: (pid 30440) 49s; run: log: (pid 479) 10376s
run: postgresql: (pid 30458) 48s; run: log: (pid 481) 10376s
run: prometheus: (pid 30470) 47s; run: log: (pid 477) 10376s
run: redis: (pid 18699) 3054s, got TERM; run: log: (pid 420) 10378s
run: redis-exporter: (pid 30582) 17s; run: log: (pid 489) 10376s
run: sidekiq: (pid 30662) 1s; run: log: (pid 491) 10376s
run: sshd: (pid 30598) 16s; run: log: (pid 36) 10388s
run: unicorn: (pid 30608) 15s; run: log: (pid 488) 10376s

解决方式
原因是目前版本下，GitLab的gitlab-ctl stop或者restart等命令似乎有时无法正常停止一些服务，比如此处为redis的进程没有停止的情况下又执行了restart产生的。此时可以结合ps -ef确认一下，确保相应的进程在停止的状态下再启动，一般此问题即可得到解决。
备份与恢复
可参看如下内容，虽然版本为GitLab 8，相关的操作基本未变化，在GitLab 12.1之前热备的命令gitlab-rake 也是一直是建议使用的，后续版本一般也是前向支持的。

https://blog.csdn.net/liumiaocn/article/details/74529908
新版本下使用旧版的gitlab-ctl进行备份和恢复的使用方式可参看：

https://liumiaocn.blog.csdn.net/article/details/107950120

原文链接：https://blog.csdn.net/liumiaocn/article/details/107926182?utm_medium=distribute.pc_feed.none-task-blog-personrec_tag-7.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-personrec_tag-7.nonecase&request_id=5f3387d22405af26f814ed51