GitLab多机备份与恢复操作
一、作用说明
备份：假设我们当前的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 root@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
迁移前-备份机目录：
迁移前-迁移机目录：
迁移后-迁移机目录：
除了访问地址不一样，其他目录结构都一样。其他操作就和原来仓库操作一样。
