docker gitlab 备份还原

灾难起源

起因是服务器 root 文件系统内存较小,只有 50G,经常爆仓。
于是乎,就把 gitlab 整体移动到内存相对较大 home 文件系统下。
这不,转移了,我人直接裂开来。

噩耗!!!

我打开命令窗口,口嚼香糖,一顿蜻蜓点水,在键盘上滑过 cp -R /app /home,刹那间,整整几个 G 的文件便搬了家。当然,其中包含着这个星期来所备份的文件。

然而,此时的我仍然在享受着香糖在口腔带来的愉悦,却不知下一秒,gitlab 的明天与意外哪个会先来。

我对着 gitlab 满心许下祝福,轻轻地敲下:

$ cd /home/app/docker/gitlab
$ docker-compose up

而此刻,等待我的却是,无尽的无尽。

gitaly cant up

有个 gitaly 服务启动失败!

失格!!!

啊,这……

在重新尝试多次启动无果后,似乎走上了一条不归路。
漆黑的命令窗口,如同深渊,凝视着你的凝视。

随着:

$ docker rm `docker ps -a | grep Exited | awk '{print $1}'`  
$ docker rmi -f `docker images | grep '<none>' | awk '{print $3}'`  

命令的执行,似乎变得清净起来。
清除了停止的容器与无用的镜像。干净的环境,总会为 gitlab 带来好运吧。然而,到头来还是一场梦。

依然启动不了 gitaly 服务,而带来的后果,就是仓库页面数据读取的失败。

gitlab 503

其他页面功能正常,仓库页面访问返回 503

返璞!!!

既然是转移之后出现的错误,那我再转移回来会报错吗?

随着我把命令喂给窗口后,gitlab 回到了原本属于它的家乡。正如同古诗句“乡音无改鬓毛衰”,此刻的 gitlab 与 它生长的 /app 环境却那么的格格不入。

依然是启动不了 gitaly,那么,gitaly 启动失败跟仓库页面 503 有什么关系呢?

Gitaly 是一个 Git RPC
服务,用于处理 GitLab 进行的所有 git 调用。
后台服务,专门负责访问磁盘以高效处理 git 操作,并缓存耗时操作。所有 git 操作都通过 Gitaly 处理。

即是 gitalygitlab 使用的处理读取 git 的桥梁服务,gitaly 开不起来,那么 gitlabgit 仓库数据的读取便是失了效。

归真!!!

经过一番查找,定位问题为数据卷挂载目录下 /app/volumes/gitlab/gitlab/repositoies/ 这个文件夹。

执行 ls,列出目录下文件:

+gitaly @hashed  @pools

有三个文件,试着把 +gitaly 文件夹删掉,重新启动 docker gitlab,发现会重新生成 +gitaly 文件夹,此时的 gitlab,好像一个捉迷藏玩的很好的孩子,藏了很久终于被发现了一样。

仓库页面已经可以打开了,除了代码仓库显示为空仓库,其他数据也可以读取了。

空仓库

执行 ls -a,大家都摊牌,别藏着掖着了:

$ ls -a
+gitaly .gitaly-metadata  @hashed  @pools

发现有一个隐藏的文件 .gitaly-metadata,查看 cat .gitaly-metadata

{"gitaly_filesystem_id":"c19d98bb-9bf7-4579-b120-c6e33902c225"}

估计就是这个生成的配置文件系统 ID 指向失效了,导致找不到 git 仓库地址。

尝试过去查找 gitaly_filesystem_id 的意义,发现源码是 ruby 函数生成,精力有限,遂无深究。

人祸湮灭

时间旅行

没错,就是恢复备份。

执行

$ cd /app/docker/gitlab
$ docker-compose run --rm gitlab app:rake gitlab:backup:restore

执行中,会让选择恢复的备份文件,输入备份 tar 包完整名称,回车即可。
如:1593450065_2020_06_29_13.0.6_gitlab_backup.tar

但是,很不幸,出现权限问题。

还原出现权限问题

还原失败

精准夺权

遇到阻碍,那就夺权。

目标是备份文件 tar 包下所有文件的用户组与所有者,都修改为 root 用户。

把备份文件 tar 包拖出来,解压到 backup 文件夹,修改权限到 root 用户组与 root 所有者。

备份文件解压

修改 backup 文件夹里面所有文件为用户组 root

chgrp -R root backup

修改 backup 文件夹里面所有文件为所有者 root

chown -R root backup

然后将夺权后的文件再重新打包为 tar 包。

继续执行:

$ cd /app/docker/gitlab
$ docker-compose run --rm gitlab app:rake gitlab:backup:restore
还原过程

虽然还有报权限错误,因为 tar.gz 包里面没有夺权,但是问题不大。

柳暗花明

回到 docker-compose.yml 目录,启动容器!

$ cd /app/docker/gitlab
$ docker-compose up

柳暗花明又一村,我胡汉三又回来了!

启动成功
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,539评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,911评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,337评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,723评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,795评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,762评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,742评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,508评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,954评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,247评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,404评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,104评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,736评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,352评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,557评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,371评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,292评论 2 352