一、作用说明
备份:假设我们当前的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 [email protected]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
迁移前-备份机目录:
迁移前-迁移机目录:
迁移后-迁移机目录:
除了访问地址不一样,其他目录结构都一样。其他操作就和原来仓库操作一样。
原文地址:https://www.cnblogs.com/shawWey/p/12205115.html