Gitlab 运维篇之——备份及恢复
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Gitlab 运维篇之——备份及恢复相关的知识,希望对你有一定的参考价值。
一、gitlab 备份方式
注意:无论哪种备份方式,一定要单独将 gitlab 的配置及密钥都单独备份,否则恢复的时候可能会出现问题,特别是:gitlab.rb 和 gitlab-secrets.json,最好 gitlab 相关的配置及证书,都单独备份。
1、gitlab 定时备份(gitlab 推荐的备份方式)
将 gitlab 及配置文件备份成一个压缩包,然后再同步到备份文件系统中,如果 postgresql 数据库单独搭建,需要单独备份 postgresql 数据库数据,一般情况下数据库会搭主从或者集群,在保证数据不会丢失的情况下可以不备份。Gitlab 备份的命令如下:
#!/bin/bash
case "$1" in
start)
gitlab-rake gitlab:backup:create SKIP=db
;;
esac
将以上代码写在 shell 脚本中,就会备份在 gitlab 配置的备份地址中,可以直接在机器上挂载 ceph 等网盘,直接把文件备份到网盘中,避免拷贝文件所需要的开销。
如果想备份 postgresql,可以用以下代码,同样可以直接存在挂载网盘上:
#!/bin/bash
BACKUP_DIR=/data1/backup/db_backups
# 如果不存在就创建
if [ ! -d "$BACKUP_DIR" ]; then
mkdir -p "$BACKUP_DIR"
fi
cd $BACKUP_DIR
# 删除30天之前的备份
deleteDIR=$(date --date=30 day ago +%Y-%m-%d)
echo $deleteDIR
rm -rf $deleteDIR
# 假设每天凌晨执行 备份数据文件夹名为昨日 yyyy-MM-dd 格式
dateDIR=$(date --date=1 day ago +%Y-%m-%d)
if [ ! -d "$dateDIR" ]; then
mkdir $dateDIR
fi
echo $dateDIR
# 使用压缩加分割的方式转储每一个数据库
pg_dump -U postgres gitlabhq_online | gzip | split -b 100m - $BACKUP_DIR/$dateDIR/gitlabhq_online_$dateDIR.gz
2、Gitlab 实时备份(采用 lsyncd 实时备份文件目录)
lsyncd 安装(Ubuntu20.04 系统)
apt install lsyncd
安装完成后执行 lsyncd --version,如果出现以下提示则表示安装成功。
lsyncd 配置-主机(/etc/lsyncd/lsyncd.conf.lua)
注意:将 ip 改成备机的 ip,如果没有配置文件新建即可
需要保证:/data1/lsyncd/logs 目录存在,不存在的话,mkdir -p /data1/lsyncd/logs
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
settings
logfile ="/data1/lsyncd/logs/lsyncd.log",
statusFile ="/data1/lsyncd/logs/lsyncd.status",
inotifyMode = "CloseWrite",
maxProcesses = 10,
sync
default.rsync,
source = "/data1/gitlab",
target = "gitlab@备份ip:/data1/backups/gitlab",
maxDelays = 50,
exclude =
"log/**"
,
delay = 60,
delete = true,
rsync =
binary ="/usr/bin/rsync",
archive = true,
compress = true,
bwlimit =5000,
sync
default.rsync,
source = "/data1/backup",
target = "gitlab@备份ip:/data1/backups/tar_back",
maxDelays = 50,
exclude =
"log/**"
,
delay = 60,
delete = true,
rsync =
binary ="/usr/bin/rsync",
archive = true,
compress = true,
bwlimit =5000,
sync
default.rsync,
source = "/etc/gitlab",
target = "gitlab@备份ip:/data1/backups/gitlab_conf",
maxDelays = 50,
exclude =
"log/**"
,
delay = 60,
delete = true,
rsync =
binary ="/usr/bin/rsync",
archive = true,
compress = true,
bwlimit =5000,
备机配置
1、备机中添加 gitlab 用户
adduser gitlab
cd /home/gitlab
mkdir .ssh
2、在主机上生成 ssh key,将公钥放到备机的.ssh/authorized_keys 中
#主机执行,一路回车即可
ssh-keygen -t rsa
#拷贝公钥
cat /root/.ssh/id_rsa.pub
#在备机中新建 authorized_keys 文件,并将主机的公钥粘进来
vim /home/gitlab/.ssh/authorized_keys
在备机中新建以下目录并修改用户和组为 gitlab
mkdir /data1/backups && cd /data1/backups
mkdir gitlab && chown -R gitlab:gitlab gitlab
mkdir gitlab_conf && chown -R gitlab:gitlab gitlab_conf
mkdir tar_back && chown -R gitlab:gitlab tar_back
3、主机上 ssh 连接下备机,回车一下,这样把备机加入到主机的信任列表里面,防止后面启动服务出错。
ssh gitlab@备份 ip
启动 lsyncd 服务及其余配置
1、启动 lsyncd
`systemctl start lsyncd `
2、设置 inotify 的最大监控文件数,注意:重启系统后会失效,需要重新设置
echo 10008192 > /proc/sys/fs/inotify/max_user_watches
systemctl restart lsyncd
修改方法 2,这个重启不失效
vim /etc/sysctl.conf
fs.inotify.max_user_watches = 99999999
systemctl restart lsyncd
进程检查
有时候,systemctl restart lsyncd 之后,通过 ps -ef|grep lsyncd 找不到进程,这个可能原因是配置文件位置错误。
cat /etc/init.d/lsyncd | grep CONFIG
确认下配置文件的位置是否和自己放的位置一致。
备份是否成功
在备机的同步目录下,查看是否同步成功
二、Gitlab 备份恢复
1、gitlab 定时备份
执行以下命令
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-rake gitlab:backup:restore BACKUP=备份的 tar 文件
gitlab-ctl reconfigure
gitlab-ctl restart
gitlab-rake gitlab:check SANITIZE=true
将 gitlab.rb 和 gitlab-secrets.json 文件放到相应的路径下,如果是在其他服务器恢复备份,一定要记得将 gitlab.rb 和 gitlab-secrets.json 手动复制到相应路径下。
gitlab.rb 路径:/etc/gitlab/gitlab.rb
gitlab-secrets.json 路径:/etc/gitlab/gitlab-secrets.json
这块如果不处理,在跳转到仓库时,gitlab 会报错 500;
2、gitlab 实时备份
将 gitlab 的仓库文件拷贝到备用 gitlab 的对应目录下,然后将配置文件放到相应的位置,重启 gitlab 即可。
三、两种方式对比
定时备份是官方推荐的备份方式,但随着仓库数量及大小的增长,备份所需要的时间也越来越长,相应的备份恢复时间也越来越长,因此,是否采用该方式备份,取决于业务方能容忍代码托管服务不可用的时间,根据我们的历史经验,100G 的压缩包,定时备份恢复时间大概在 2h 左右。
实时备份将 gitlab 的文件实时同步到备份服务器上,只需要修改 gitlab 的配置,并将关键配置文件拷贝过去,重启 gitlab 即可,因此实时备份的时间可控制在 30min 内,不受仓库数量及大小的影响,如果经过比较充分的演练,可以将时间再降低。
以上是关于Gitlab 运维篇之——备份及恢复的主要内容,如果未能解决你的问题,请参考以下文章
Exchange Server 2016运维篇三:恢复删除的邮箱
Exchange Server2016运维篇二:恢复禁用的邮箱