Gitlab篇：Gitlab 数据备份与迁移

一、Gitlab篇：Gitlab 数据备份与迁移

01 前言

虽说Git是分布式的，但是自从经历了上次Jira/Confluence 数据丢失的惨痛教训，为了以防万一，还是每天备份一下吧

02 备份方式

gitlab在服务器的默认备份文件存储在以下文件夹

/var/opt/gitlab/backups

可以通过/etc/gitlab/gitlab.rb配置文件，查看一个和备份相关的配置项，可自行修改路径：

gitlab_rails['backup_path'] ="/var/opt/gitlab/backups"    #备份目录可以修改

备份命令用gitlab自带的

gitlab-rake gitlab:backup:create

假如备份路径没改，会在/var/opt/gitlab/backups目录下生成一个tar文件，如下：

1530156812_2019_11_14_10.8.4_gitlab_backup.tar

其中，530156812_2019_11_14_10.8.4 这一串数字就是备份编号，在恢复的时候用的到。

这里我们不修改路径，加到crontab中定时执行：

0  2 *  *  * /opt/gitlab/bin/gitlab-rake gitlab:backup:create  >/dev/null2>&1

gitlab-ce自身集成的有自动删除备份配置。打开/etc/gitlab/gitlab.rb配置

gitlab_rails['backup_keep_time'] = 604800

设置备份保留7天（7x3600x24=604800）秒为单位。

大家可视磁盘空间设置备份文件保留周期

03 数据恢复

停掉数据连接服务

gitlab-ctl  stop  unicorn

gitlab-ctl  stop  sidekiq

恢复

gitlab-rake gitlab:backup:restoreBACKUP=备份编号

注：1、到底那个是备份编号？

    --- _gitlab之前的部分都是；

2、644默认权限。

查看恢复状态：

gitlab-rake gitlab:checkSANITIZE=true

重启服务

gitlab-ctl  start  unicorn

gitlab-ctl  start  sidekiq

或

gitlab-ctl restart

这里主要讲备份，具体的参考文章为：Gitlab备份、迁移、恢复和升级

# 二、day112 gitlab的迁移与升级

升级思路：先在新服务器上安装一个和原版本相同版本的gitlab，然后备份原版本gitlab数据，备份完在新服务器恢复，恢复完在进行升级。
1.查看gitlab版本的命令:

gitlab-rake gitlab:env:info

备份原老服务器上的的数据

gitlab-rake gitlab:backup:create RAILS_ENV=production

PS: 备份后的文件一般是位于/var/opt/gitlab/backups下, 自动生成文件名文件名如1481529483_gitlab_backup.tar

将步骤2生成的tar文件拷贝到新服务器上相应的backups目录下
可以利用scp进行直接拷贝.

scp username@src_ip:/var/opt/gitlab/backups/1481529483_gitlab_backup.tar /var/opt/gitlab/backups

PS: username为原服务器的用户名，src_ip原服务器IP地址
在新服务器恢复数据

gitlab-rake gitlab:backup:restore RAILS_ENV=production BACKUP=1481529483

PS：BACKUP的时间点必须与原服务器备份后的文件名一致

5.出错解决：

数据迁移到后检查登录gialab有时候会跳出500报错(Something went wrong on our end.)以及无法正常新建用户

查看日志:tail -f /var/log/gitlab/redis/current

Can't save in background: fork: Cannot allocate memory

解决方案:

修改/etc/sysctl.conf

加上vm.overcommit_memory = 1, Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

修改完执行sysctl -p

vm.overcommit_memory = 1，直接放行

vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。

vm.overcommit_memory = 2：则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内
在升级前一定要做好备份，记录自己当前gitlab-ca的版本号。
查看当前gitlab版本号

[root@localhost ~]``# yum list | grep gitlab-ce
gitlab-ce.x86_64 11.4.3-ce.0.el7 installed

备份文件

[root@localhost ~]# gitlab-rake gitlab:backup:create

在/var/opt/gitlab/backups下会生成一个备份文件如：1557218709_2019_05_07_9.2.2_gitlab_backup.tar，其中1557218709即为此次备份都版本号。

还原备份
执行

gitlab-rake gitlab:backup:restore BACKUP=备份版本号

（一）配置gitlab-yum源

[root@localhost ~]# cat << EOF > /etc/yum.repos.d/gitlab-ce.repo

[gitlab-ce]
name=gitlab-ce
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
repo_gpgcheck=0
gpgcheck=0
enable=1
gpgkey=https://packages.gitlab.com/gpg.key
EOF

（二）yum localinstall安装

注意：Gitlab的升级不能跨越大版本号，因此只能升级到当前大版本号到最高版本，方可升级到下一个大版本号。
需要做的升级步骤如下：
11.4.3->11.11.8->12.0.9
1、准备好相关的rpm包

wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.11.8-ce.0.el7.x86_64.rpm
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-12.0.9-ce.0.el7.x86_64.rpm

2、依次执行下面指令逐步升级，在每一步安装成功后如果发现界面500，执行gitlab-ctl reconfigure指令刷新配置文件。（一定保证数据可以正常访问方可执行下一步升级指令）

yum localinstall -y gitlab-ce-11.11.8-ce.0.el7.x86_64.rpm
yum localinstall -y gitlab-ce-12.0.9-ce.0.el7.x86_64.rpm

完成之后再查看下当前的版本：

[root@gitlab ~]# cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
12.0.9

# 三、介绍gitlab的备份恢复与升级

几乎任何应用系统都规避不开的三个问题：备份、恢复和升级。相对而言来说，gitlab-ce虽然是一个开源免费产品，但在这三方面做的还是比较人性化的。下面逐个介绍。

一、数据备份

先打开/etc/gitlab/gitlab.rb配置文件，查看一个和备份相关的配置项：

gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

该项定义了默认备份出文件的路径，可以通过修改该配置，并执行gitlab-ctl restart 重启服务生效。备份执行一条命令就搞定：/opt/gitlab/bin/gitlab-rake gitlab:backup:create ，也可以加到crontab中定时执行：

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

可以到/var/opt/gitlab/backups找到备份包，解压查看，会发现备份的还是比较全面的，数据库、repositories、build、upload等分类还是比较清晰的。

每天执行备份，肯定有目录被爆满的风险，我们可以立马想到的可以通过find 查找一定的时间前的文件，配合rm进行删除。不过不需要这么麻烦，gitlab-ce自身集成的有自动删除配置。同样打开/etc/gitlab/gitlab.rb配置文件，可以找到如下配置：

gitlab_rails['backup_keep_time'] = 604800

这里是设置备份保留7天（7360024=604800），秒为单位，如果想增大或减小，可以直接在该处配置，并通过gitlab-ctl restart 重启服务生效。

二、数据恢复

恢复前需要先停掉数据连接服务：

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq

如果是台空主机，没有任何操作，理论上不停这两个服务也可以。停这两个服务是为了保证数据一致性。如果你没修改过默认备份目录的话，将老服务器/var/opt/gitlab/backups目录下的备份文件拷贝到新服务器上的/var/opt/gitlab/backups，执行下面的命令进行恢复：

gitlab-rake gitlab:backup:restore BACKUP=备份编号

上个图，看的更直观：
介绍gitlab的备份恢复与升级

上面的操作中，有两个注意点：

1、到底那个是备份编号？ — _gitlab之前的部分都是；

2、600权限是无权恢复的。 — 这里改成了777；

后面再输入两次yes就完成恢复了。

恢复完成后，启动刚刚的两个服务，或者重启所有服务，再打开浏览器进行访问，发现数据和之前的一致：

gitlab-ctl start unicorn
gitlab-ctl start sidekiq
或
gitlab-ctl restart

还有一点要别注注意，根据以往的经验，通过备份文件恢复gitlab必须保证两台主机的gitlab版本一致，否则会提示版本不匹配。

三、gitlab-ce升级

升级比较简单，但最好不要跨越太大的版本，版本差别比较大时，最好逐个版本往上升。

关闭gitlab服务

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl stop nginx

备份gitlab

gitlab-rake gitlab:backup:create

升级rpm包

rpm -Uvh gitlab-ce-xxx.rpm

启动并查看gitlab版本信息

gitlab-ctl reconfigure
gitlab-ctl restart
head -1 /opt/gitlab/version-manifest.txt

可能遇到的报错，

Error executing action `run` on resource 'ruby_block[directory resource: /var/opt/gitlab/git-data/repositories]'
解决方法:
sudo chmod 2770 /var/opt/gitlab/git-data/repositories

参考链接 ：
day112 gitlab的迁移与升级 ：https://www.jianshu.com/p/9d142eb67960

Gitlab篇：Gitlab 数据备份与迁移
https://www.jianshu.com/p/c9f3dc7ba5cd

介绍gitlab的备份恢复与升级 ：https://www.jianshu.com/p/61c0c2241012