Gitlab备份以及恢复

1.迁移准备工作和思路

从a服务器迁移到b服务器,由于Gitlab自身的兼容性问题，高版本的Gitlab无法恢复低版本备份的数据,需要注意在b服务器部署和a服务器一样版本的gitlab,部署好环境后开始备份和数据迁移.

查看gitlab版本的命令:

 gitlab-rake gitlab:env:info

2. 备份原a服务器上的的数据

gitlab-rake gitlab:backup:create RAILS_ENV=production

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

这里要特别说明，如果在/etc/gitlab/gitlab.rb 文件配置了参数“backup_path”（例如gitlab_rails['backup_path'] = '/backup'），

则备份的目录就是该目录下（/backup/），如果没有配置参数“backup_path”，则gitlab把备份文件生成到默认目录
/var/opt/gitlab/backups。

大意就是在gitlab.rb和gitlab-secrets.json文件中包含敏感数据，在备份中并没有包含这两个文件，需要手动保存一下，

在恢复备份的时候会需要这两个文件（如果是在本机更新，则不备份这两个文件也没关系，

如果是备份了在另一台机器安装gitlab并恢复数据，则需要在另一台机器覆盖这两个文件）。

这两个文件放在/etc/gitlab目录下。

3. 将步骤2生成的tar文件拷贝到b服务器上相应的backups目录下

可以利用scp进行直接拷贝.

scp /var/opt/gitlab/backups/1592188481_2020_06_15_13.0.3_gitlab_backup.tar  username@desc_ip:/var/opt/gitlab/backups

PS: username为目的服务器的用户名，desc_ip目的服务器IP地址

4. 在b服务器恢复数据

gitlab-rake gitlab:backup:restore RAILS_ENV=production BACKUP=/var/opt/gitlab/backups/1592188481_2020_06_15_13.0.3

PS：注意恢复备份使用的文件名称，使用的是文件名中git前边的数据

1592188481_2020_06_15_13.0.3_gitlab_backup.tar ==> 1592188481_2020_06_15_13.0.3

开始恢复的时候会有个警告提示，手动输入'yes'继续操作就行
然后在遇到authorized_keys时，也手动输入'yes'继续操作就行

恢复后的界面

5. 通过脚本定时备份

写一个简单的脚本，加入到定时任务，以保证每天备份一次代码到异地。

写脚本之前，先创建一下对应的工作目录：

mkdir /backup
touch /backup/logfile.txt

脚本内容如下：

#!/bin/bash
Bakupdir=/var/opt/gitlab/backups/
Logfile=/backup/logfile.txt
Date=`date +%Y-%m-%d`
gitlab-rake gitlab:backup:create RAILS_ENV=production
if [ $? -eq 0 ];then
    echo "$Date Backup Successful" >> $Logfile
else
    echo "$Date Backup Failed" >> $Logfile
fi
cd $Bakupdir
scp *.tar backup@192.168.106.222:/home/backup/gitbak # 提前创建好目录，ssh免密登陆等
rm -rf *

然后将脚本加入定时任务，根据需求，定期执行即可！

6.出错解决

数据迁移到后检查登录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：则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内