一、作用说明

备份：假设我们当前的gitlab挂掉了，整个服务器都起不来了，但是我们有对gitlab的归档备份，这时候还可以恢复出数据来。

迁移：假设此时使用的gitlab服务器出现故障运行不了，但是我们对gitlab在远端机有归档备份，这时候我们就可以在远端机把数据恢复重新搭建gitlab。

注意的是：备份和迁移的恢复操作是全量的，操作前要确认是否要进行备份或者恢复操作。

二、前提条件

在新的主机安装与之前机器相同版本的gitlab rpm包。也就是说要保证两台或者多台机器安装的gitlab版本要一致。可以通过以下命令查看相关git版本以及安装目录。

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

或者可以通过管理区域查看相关的GitLab版本信息：

三、备份恢复流程 

备份机：需要gitlab备份所在的机子 

迁移机：gitlab需要迁移的机子，即新服务器所在机子 

备份恢复流程图：

配置文件说明： 

/etc/gitlab/gitlab.rb 配置文件须备份 

/var/opt/gitlab/nginx/conf nginx配置文件 

/etc/postfix/main.cfpostfix 邮件配置备份

3.1 备份机备份文件

备份时需要保持gitlab处于正常运行状态，在备份机直接执行以下命令：

gitlab-rake gitlab:backup:create

备份机会默认在/var/opt/gitlab/backups目录下创建一个名称类似为1573460229_2019_11_11_9.3.0_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1573460229_2019_11_1是备份创建的日期。文件如图所示：

也提供了以下几种方式进行相关备份工作的配置：

3.1.1自动备份时间配置

在crontab文件里面，每一行代表一项任务，每行的每个字段代表一项设置，它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，每个字段之间用空格分割，没用的段用*代替，格式如下：

m h dom mon dow user command

其中：

m：表示分钟，可以是从0到59之间的任何整数。

h：表示小时，可以是从0到23之间的任何整数。

dom：表示日期，可以是从1到31之间的任何整数。

mon：表示月份，可以是从1到12之间的任何整数。

dow：表示星期几，可以是从0到7之间的任何整数，这里的0或7代表星期日。

user : 表示执行的用户。

command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件(如shell文件)。

实现每天凌晨2点进行一次自动备份:通过crontab使用备份命令实现，需重启cron服务

方法1:在命令行输入: crontab -e 然后添加相应的任务，wq存盘退出。

#输入命令crontab -e
sudo crontab -e  
#输入相应的任务
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

方法2:直接编辑/etc/crontab 文件，即vi /etc/crontab，添加相应的任务

#编辑 /etc/crontab
vi /etc/crontab 
然后再编辑框内输入相应的任务
# edited by ouyang 2017-8-11 添加定时任务，每天凌晨两点，执行gitlab备份
0  2    * * *   root    /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

方法3：通过编写sh脚本执行

或者直接定时执行一个脚本 auto_backup.sh ，脚本内容为

/opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

然后再 /etc/crontab中，添加相关任务定时执行 auto_backup.sh 脚本文件　　

sudo chmod +x auto_backup.sh
sudo vim auto_backup.sh

/etc/crontab 中添加执行脚本的定时任务，代码如下：

#也可以按照如下所示的方法，定时执行 auto_backup.sh脚本，脚本内容就填写： /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1 

0 2    * * *   root    /data/gitlabData/backups/auto_backup.sh -D 1

编写完 /etc/crontab 文件之后，需要重新启动cron服务

#重新加载cron配置文件
sudo /usr/sbin/service cron reload
#重启cron服务
sudo /usr/sbin/service cron restart

3.1.2修改默认备份路径 

 打开备份机gitlab的/etc/gitlab/目录下的gitlab.rb文件，找到以下配置信息，即可修改文件备份路径： 

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

修改完之后，执行以下命令，重新配置下gitlab

gitlab-ctl reconfigure 或者 gitlab-ctl  restart

比如：修改了备份路径：

重新执行备份语句gitlab-rake gitlab:backup:create，生成文件如下：

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

3.1.3修改备份保留时间

每天执行备份，肯定有目录被爆满的风险，gitlab-ctl自身集成的有自动删除配置。同样打开/etc/gitlab/gitlab.rb配置文件，可以找到如下配置： 

gitlab_rails[‘backup_keep_time‘] = 604800 

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

3.2 发送或者拷贝备份文件至迁移机

3.2.1发送备份文件 

在备份机上打开/var/opt/gitlab/backups，通过以下命令将备份文件发送到迁移机具体备份路径或者通过ftp上传到具体路径： 

rsync -avz 1573517815_2019_11_12_9.3.0_gitlab_backup.tar  192.111.25.32:/var/opt/gitlab/backups/ 

要输入迁移机的密码，等待执行完毕。 

3.2.2本地拷贝备份文件 

在迁移机上打开/var/opt/gitlab/backups，通过以下命令将备份文件拷贝到迁移机具体备份路径上： 

scp 192.111.35.142:/var/opt/gitlab/backups/1573517815_2019_11_12_9.3.0_gitlab_backup.tar /var/opt/gitlab/backups/

要输入备份机的密码，等待执行完毕。 

3.3 迁移机恢复备份 

3.3.1将备份文件权限修改为777 

第一步，将备份文件权限修改为777，不然可能恢复的时候会出现权限不够，不能解压的问题 

chmod 777 1502357536_2017_08_10_9.4.3_gitlab_backup.tar 

3.3.2执行命令停止相关数据连接服务 

执行命令停止相关数据连接服务，防止恢复备份的同时还有数据操作，导致数据不一致： 

# 停止相关数据连接服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq 

3.3.3执行命令从备份文件中恢复Gitlab

进入到迁移机/var/opt/gitlab/backups目录执行下面的命令进行恢复： 

gitlab-rake gitlab:backup:restore BACKUP=1573440757_2019_11_11_9.3.0
或者
gitlab-rake gitlab:backup:restore BACKUP=1573440757_2019_11_11_9.3.0_gitlab_backup.tar

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

3.3.4启动Gitlab

第四步，启动Gitlab

sudo gitlab-ctl start

迁移前-备份机目录：

迁移前-迁移机目录：

迁移后-迁移机目录： 

除了访问地址不一样，其他目录结构都一样。其他操作就和原来仓库操作一样。