gitlab仓库管理 GitLab 备份、恢复、升级
GitLab 备份、恢复、升级
gitlab放着企业的源码，源码很重要 gitlab备份非常重要
对 gitlab 进行备份将会创建一个包含所有库和附件的归档文件。
对备份的恢复只能恢复到与备份时的 gitlab 相同的版本。
将 gitlab 迁移到另一台服务器上的最佳方法就是通过备份和还原。
gitlab 提供了一个简单的命令行来备份整个 gitlab，并且能灵活的满足需求
备份配置
备 份 文 件 将 保 存 在 配 置 文 件 中 定 义 的 backup_path 中 ， 文 件 名 为
TIMESTAMP_gitlab_backup.tar,TIMESTAMP 为备份时的时间戳。TIMESTAMP 的格式为：
EPOCH_YYYY_MM_DD_Gitlab-version。
默认的备份文件目录为：/var/opt/gitlab/backups，如果自定义备份目录需要赋予目录 git 权限，具体操作如下：
配置文件/etc/gitlab/gitlab.rb
配置文件中加入
路径
gitlab_rails['backup_path'] = '/data/backup/gitlab'
gitlab_rails['backup_keep_time'] = 604800 #备份保留的时间（以秒为单位， 这个是七天默认值）
创建备份目录
[root@ci-node1 git_test]# mkdir -p /data/backup/gitlab
vim /etc/gitlab/gitlab.rb
加到最后
保存 wq退出
改完配置执行gitlab-ctl reconfigure
[root@ci-node1 git_test]# gitlab-ctl reconfigure
如果自定义备份目录需要赋予目录 git 权限
chown -R git.git /data/backup/gitlab
执行完gitlab-ctl reconfigure 他会自动帮助我们创建好备份目录的
[root@ci-node1 git_test]# ll /data/backup/gitlab/
权限也不用改 创建的备份目录 和默认备份目录权限一样
[root@ci-node1 git_test]# ll /data/backup/ total 0 drwx------ 2 git root 6 Apr 5 22:26 gitlab
[root@ci-node1 git_test]# ls -dl /var/opt/gitlab/backups/ drwx------ 2 git root 6 Mar 22 23:25 /var/opt/gitlab/backups/
手动备份
在命令执行：/usr/bin/gitlab-rake gitlab:backup:create 生成一次备份
[root@ci-node1 git_test]# /usr/bin/gitlab-rake gitlab:backup:create Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] done Dumping repositories ... * test/git_test ... [DONE] * test/git_test.wiki ... [SKIPPED] done Dumping uploads ... done Dumping builds ... done Dumping artifacts ... done Dumping pages ... done Dumping lfs objects ... done Dumping container registry images ... [DISABLED] Creating backup archive: 1586097870_2020_04_05_10.2.2_gitlab_backup.tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done done done done done done done Deleting old backups ... done. (0 removed)
[root@ci-node1 git_test]# ll /data/backup/gitlab/ total 72 -rw------- 1 git git 71680 Apr 5 22:44 1586097870_2020_04_05_10.2.2_gitlab_backup.tar
时间搓 年月日 gitlab版本号
备份包括所有库，文档 打包成一个压缩包
我们看到在设定的目录中生成了对应的备份文件
定时备份
定时任务crontab中加入
通过在定时任务里添加：
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
我们来实现定时备份，由于代码是一个企业非常重要的资产，所以我们要重视 GitLab的备份工作。
至少做到每天备份一次，平时要注意检查备份的完整性。 至少每天一次全量的备份
环境变量 CRON=1 的作用是如果没有任何错误发生时， 抑制备份脚本的所有进度输出
备份不用去删除，默认保留7天 配置文件里面可以修改备份保留的时间
gitlab恢复实践
在gitlab 试下删库，然后用备份恢复
进入仓库
点击
输入仓库名称
删除了
GitLab 的恢复只能还原到与备份文件相同的 gitlab 版本的系统中，恢复时，停止连接
到数据库的进程（也就是停止数据写入服务），但是保持 GitLab 是运行的
停止数据写入服务
如果不停止数据写入，会有变恢复 边写数据 会乱
停止数据写入 执行这两条命令 停两个服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
[root@ci-node1 git_test]# gitlab-ctl stop unicorn
ok: down: unicorn: 0s, normally up
[root@ci-node1 git_test]# gitlab-ctl stop sidekiq
ok: down: sidekiq: 0s, normally up
确认一下
[root@ci-node1 git_test]# gitlab-ctl status run: gitaly: (pid 6501) 501642s; run: log: (pid 6494) 501642s run: gitlab-monitor: (pid 6492) 501642s; run: log: (pid 6487) 501642s run: gitlab-workhorse: (pid 6491) 501642s; run: log: (pid 6486) 501642s run: logrotate: (pid 109050) 423s; run: log: (pid 6479) 501642s run: nginx: (pid 6503) 501642s; run: log: (pid 6496) 501642s run: node-exporter: (pid 6482) 501642s; run: log: (pid 6481) 501642s run: postgres-exporter: (pid 6504) 501642s; run: log: (pid 6497) 501642s run: postgresql: (pid 6490) 501642s; run: log: (pid 6485) 501642s run: prometheus: (pid 6499) 501642s; run: log: (pid 6498) 501642s run: redis: (pid 6489) 501642s; run: log: (pid 6484) 501642s run: redis-exporter: (pid 6502) 501642s; run: log: (pid 6495) 501642s down: sidekiq: 46s, normally up; run: log: (pid 6493) 501642s down: unicorn: 115s, normally up; run: log: (pid 6483) 501642s
接下来执行 gitlab 恢复操作：
gitlab-rake gitlab:backup:restore BACKUP=备份文件名
文件名只要数字部分就可以了
[root@ci-node1 git_test]# gitlab-rake gitlab:backup:restore BACKUP=1586097870_2020_04_05_10.2.2 Unpacking backup ... done Before restoring the database, we will remove all existing tables to avoid future upgrade problems. Be aware that if you have custom tables in the GitLab database these tables and all data will be removed. Do you want to continue (yes/no)?
一直按yes
整个恢复执行过程中，我们可以看到基本是在删除表，创建表。
完成后把gitlab 服务重启
gitlab-ctl restart
[root@ci-node1 git_test]# gitlab-ctl restart ok: run: gitaly: (pid 109574) 0s ok: run: gitlab-monitor: (pid 109590) 1s ok: run: gitlab-workhorse: (pid 109593) 0s ok: run: logrotate: (pid 109636) 0s ok: run: nginx: (pid 109642) 1s ok: run: node-exporter: (pid 109647) 0s ok: run: postgres-exporter: (pid 109651) 1s ok: run: postgresql: (pid 109658) 0s ok: run: prometheus: (pid 109666) 1s ok: run: redis: (pid 109673) 0s ok: run: redis-exporter: (pid 109677) 0s ok: run: sidekiq: (pid 109693) 1s ok: run: unicorn: (pid 109700) 0s
确认下 两个服务启动了
[root@ci-node1 git_test]# gitlab-ctl status run: gitaly: (pid 109574) 28s; run: log: (pid 6494) 502050s run: gitlab-monitor: (pid 109590) 26s; run: log: (pid 6487) 502050s run: gitlab-workhorse: (pid 109593) 25s; run: log: (pid 6486) 502050s run: logrotate: (pid 109636) 25s; run: log: (pid 6479) 502050s run: nginx: (pid 109642) 25s; run: log: (pid 6496) 502050s run: node-exporter: (pid 109647) 24s; run: log: (pid 6481) 502050s run: postgres-exporter: (pid 109651) 24s; run: log: (pid 6497) 502050s run: postgresql: (pid 109658) 23s; run: log: (pid 6485) 502050s run: prometheus: (pid 109666) 23s; run: log: (pid 6498) 502050s run: redis: (pid 109673) 22s; run: log: (pid 6484) 502050s run: redis-exporter: (pid 109677) 22s; run: log: (pid 6495) 502050s run: sidekiq: (pid 109693) 22s; run: log: (pid 6493) 502050s run: unicorn: (pid 109700) 21s; run: log: (pid 6483) 502050s
再看看gitlab页面 看看仓库回来了吗
恢复完成
升级
首先，下载新版本的 RPM 包，可以通过官网或者清华镜像站获取。
其次关闭部分 gitlab 服务
关闭数据写入服务 关闭nginx 这三个服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl stop nginx
执行升级操作
rpm -Uvh gitlab-ce-10.0.4-ce.0.el7.x86_64.rpm
完成后重新配置 gitlab
gitlab-ctl reconfigure
重启 gitlab 服务
gitlab-ctl restart
注：升级操作不建议进行。 有风险
如果确实需要，也可以采取在一台新的服务器上安装新版本的 Gitlab，然后采用导入库的方式将旧系统的代码仓库导入到新 Gitlab 上。
如果不行 可以撤回来
