自建的Gitlab服务器常常会因为使用时间的增长，其空间容量等硬件需求都需要升级，或者迁移至更高配置的服务器上。备份、迁移、恢复、升级过程如下
一、gitlab备份
1、修改仓库存储位置
gitlab通过rpm包安装后，默认存储位置在/var/opt/gitlab/git-data/repositories，通常需要更改此路径到单独的一个分区来存储仓库的数据。
这里我把数据存放到/home/gitlab-data目录下
mkdir -p 即使上级目录不存在，会按目录层级自动创建目录
mkdir -p /home/gitlab-data
修改gitlab配置文件，找到git_data_dir
vim /etc/gitlab/gitlab.rb
重新加载配置
sudo gitlab-ctl reconfigure
重新加载后，会发现在/home/git-data目录下多出一个repositories目录
重启
sudo gitlab-ctl restart
2、修改备份文件目录
备份的位置可以更换,使用如下命令：(默认可以不修改,那么默认生成在/var/opt/gitlab/backups)可以通过/etc/gitlab/gitlab.rb配置文件来修改默认存放备份文件的目录vim /etc/gitlab/gitlab.rb
取消注释并修改为自定义备份路径gitlab_rails['backup_path'] = "/home/gitlab-backups"
重读配置
sudo gitlab-ctl reconfigure
重启
sudo gitlab-ctl restart
3、通过gitlab-rake命令备份gitlab
备份时需要保持gitlab处于正常运行状态，直接执行gitlab-rake gitlab:backup:create进行备份(需要sudo权限,不然报错)gitlab提供的备份命令为gitlab-rake，备份命令使用如下:sudo gitlab-rake gitlab:backup:create使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1530156812\_\_06\_28\_10.8.4\_gitlab\_backup.tar的压缩包,这个压缩包就是Gitlab整个的完整部分, 其中开头的1530156812\_\_06\_28\_10.8.4是备份创建的日期;
该命令会备份gitlab仓库、数据库、用户、用户组、用户密钥、权限等信息。
备份完成后备份文件会出现在/var/opt/gitlab/backups/
红字部分表示 gitlab.rb 和 gitlab-secrets.json 两个文件包含敏感信息。未被备份到备份文件中。需要手动备份。
这两个文件在/etc/gitlab/ 目录下，我们进入目录使用cp命令复制到自定义的备份目录
cp gitlab.rb gitlab-secrets.json /home/gitlab-backups/
4、设置备份过期时间
[root@gitlab ~\]# vim /etc/gitlab/gitlab.rbgitlab\_rails\['backup\_keep\_time'\] = 604800 #以秒为单位
5、自动备份方案
创建定时任务[root@gitlab ~\]# crontab -e0 2 \* \* \* /opt/gitlab/bin/gitlab-rake gitlab:backup:create
minute： 表示分钟，可以是从0到59之间的任何整数。
hour： 表示小时，可以是从0到23之间的任何整数。
day： 表示日期，可以是从1到31之间的任何整数。
month： 表示月份，可以是从1到12之间的任何整数。
week： 表示星期几，可以是从0到7之间的任何整数，这里的0或7代表星期日。
command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。
在书写 crontab 定时任务时，需要注意以下几个事项：
1、6 个选项都不能为空，必须填写。如果不确定，则使用"*"代表任意时间。
2、crontab 定时任务的最小有效时间是分钟，最大有效时间是月。像 年某时执行、3 点 30 分 30 秒这样的时间都不能被识别。
3、在定义时间时，日期和星期最好不要在一条定时任务中出现，因为它们都以天为单位，非常容易让管理员混淆。
4、在定时任务中，不管是直接写命令，还是在脚本中写命令，最好都使用绝对路径。有时使用相对路径的命令会报错。
方法1.每天自动备份gitlab，并只保留近7天备份
编辑备份脚本vim /var/opt/gitlab/gitbackup.sh# !/bin/bashgitlab-rake gitlab:backup:create CRON=1将该脚本加入crontab中执行，每天凌晨1点备份crontab -e：//进入crontab编辑模式0 1 * /var/opt/gitlab/gitbackup.sh &>/dev/nullvim /etc/gitlab/gitlab.rb找到gitlab_rails['backup_keep_time'] = 604800取消注释,gitlab-ctl reconfigure重读配置gitlab-ctl restart 重启
方法2.以实现每天凌晨4点进行一次自动备份为例，系统的crontab配置如下:
vim /etc/crontab0 4 * * * root /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
然后重启crontab服务，如下：
systemctl restart crond
二、gitlab仓库恢复
要验证gitlab备份的有效性，我们可以把该备份文件复制到已经安装好gitlab服务器的/var/opt/gitlab/backups/目录下。然后进行数据恢复，最后访问并查看其数据完整性即可。通过gitlab备份文件可以恢复gitlab所有的信息，包括仓库、数据库、用户、用户组、用户密钥、权限等信息。ps：新服务器上的gitlab的版本号必须与创建备份时的gitlab版本号相同。gitlab数据恢复比较简单，具体步骤如下：
1、停止相关数据连接服务
gitlab-ctl stop unicorngitlab-ctl stop sidekiq
2、恢复gitlab仓库
进入/var/opt/gitlab/backups
现在我们要从1537261122__09_18_9.2.5这个备份编号中，恢复数据，命令如下：
gitlab-rake gitlab:backup:restore BACKUP=1546916920__01_08_10.5.1
按照提示输入两次yes并回车
如果出现多个done的信息，说明整个gitlab数据就已经正常恢复完毕。
4、恢复两个配置文件
我们进入备份目录使用cp命令复制到配置目录
cp gitlab.rb gitlab-secrets.json /etc/gitlab/
5、恢复完毕以后，我们现在来启动gitlab，使用以下命令：
gitlab-ctl start
三、gitlab迁移
迁移的整体思路是：
1、在新服务器上安装相同版本的gitlab
2、将备份生成的备份文件发送到新服务器的相同目录下
这里在10.0.0.6的机器上安装了相同版本的gitlab并能正常运行使用
在老服务器上将备份文件发送至新服务器的相应目录下，然后在使用恢复命令即可
