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

迁移前-备份机目录:

  

迁移前-迁移机目录:

 

迁移后-迁移机目录: 

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

posted @ 2020-01-17 11:54  shawWey  阅读(751)  评论(0编辑  收藏