GitLab基础：备份与恢复指南

GitLab提供进行备份和恢复的方式，整体来说，备份的过程会创建包含数据库、所有仓库和附件的归档文件。无论是CE版本还是EE版本，GitLab恢复数据的时候都需要满足版本一致的前提，即进行恢复的GitLab的版本和备份数据时的GitLab的版本一致。

备份文件

保存目录

备份文件缺省保存的目录在/etc/gitlab/gitlab.rb文件中可以进行配置，缺省状态下备份文件会保存在/var/opt/gitlab/backups目录下，可以打开如下注释，并根据需要修改备份文件的保存目录。

# gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

文件名

文件名格式：[TIMESTAMP]_gitlab_backup.tar

需要注意得是从GitLab 9.2版本开始[TIMESTAMP]的格式发生了变化

• GitLab 9.2之前：EPOCH_YYYY_MM_DD
• GitLab 9.2之后：EPOCH_YYYY_MM_DD_GitLab_version

而实际上这仅仅是一个文件名称的改变而已，比如使用旧版的备份命令在新版的GitLab中生成了EPOCH_YYYY_MM_DD_GitLab_version格式的文件，而实际上只修改此文件至原有版本也可以正常运行，详细可参看以下的验证示例：

• https://liumiaocn.blog.csdn.net/article/details/107950120

GitLab备份

使用命令

可以使用如下命令进行GitLab的备份：

执行命令（GitLab 12.1之后版本）：gitlab-backup create

或者

执行命令（GitLab 12.1及之前版本）：gitlab-rake gitlab:backup:create

备份文件

备份所生成的tar归档文件，实际是有如下目录所组成，各目录所保存的数据内容和目录名称如下所示：

目录名称	备份文件说明
db	数据库备份：主要为PostgreSQL数据库数据内容
uploads	附件数据备份
repositories	Git仓库数据备份
builds	CI Job输入日志等数据备份
artifacts	CI Job构件数据备份
lfs	LFS对象数据备份
registry	容器镜像备份
pages	GitLab Pages content数据备份

备份执行示例

# gitlab-rake gitlab:backup:create
2020-08-19 04:46:08 +0000 -- Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... [DONE]
2020-08-19 04:46:13 +0000 -- done
2020-08-19 04:46:13 +0000 -- Dumping repositories ...
 * root/webhookproject (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b) ... [DONE]
[SKIPPED] Wiki
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping uploads ... 
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping builds ... 
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping artifacts ... 
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping pages ... 
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping lfs objects ... 
2020-08-19 04:46:14 +0000 -- done
2020-08-19 04:46:14 +0000 -- Dumping container registry images ... 
2020-08-19 04:46:14 +0000 -- [DISABLED]
Creating backup archive: 1597812374_2020_08_19_12.10.5_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 ... skipping
Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data 
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.
Backup task is done.
# 

手工备份文件

执行上述备份命令时也会提示了由于安全的关系如下的配置文件需要手工去备份和恢复：

• /etc/gitlab/gitlab-secrets.json
• /etc/gitlab/gitlab.rb

备份策略

缺省方式下的备份主要是通过使用Linux的tar和gzip命令来完成的，但是这种方式在数据快速变化的情况下会发生问题。当tar命令在执行的时候，如果被归档的文件此时正在修改过，类似“tar: xxxx: file changed as we read it”的错误护信息就会在备份执行的过程中出现并导致整个备份过程失败。为了解决这个问题在8.17版本引入了一种新的备份策略名为copy，copy策略会将数据拷贝至一个临时路径下，然后再执行tar和gzip命令，这样就避免了这种故障的发生。

但是副作用也非常明显，就是备份的时候需要多一倍的磁盘使用量，对于体量较大时还是需要慎重考虑的，这也是为何在8.17版本中copy策略并非缺省设定的原因。使用copy策略替代缺省方式，只需要指定STRATEGY=copy即可，执行命令如下所示：

执行命令（GitLab 12.1及之前版本）：gitlab-rake gitlab:backup:create STRATEGY=copy

注：另外，在使用GlusterFS也出现了类似的问题，当时并未解决（使用上述官方提示的copy策略并未得到解决），后来因为其他的原因不再使用GlusterFS此问题不再存在不了了之。

指定备份文件名称

缺省方式之下，GitLab的备份文件中会包含时间戳作为前缀，此部分也可以通过BACKUP=指定信息 进行替换，比如执行下述命令：

执行命令（GitLab 12.1及之前版本）：gitlab-rake gitlab:backup:create BACKUP=dump

则会生成一个名为dump_gitlab_backup.tar的备份文件，这个选项之所以目前比较重要的原因是因为这是GitLab提供的增量备份的一种方式。

增量方式

准确来说这并不是严格的增量方式，而只是为了保证产生的归档文件能够使用rsync更加智能的传输，什么叫做比较智能的传输？实际就是增量式的传输，已有的内容不再传输，所以这就是上文提到指定文件名称的选项为何是增量备份中的一环的原因。通过设定GZIP_RSYNCABLE选项为yes，而此项可有可无的增量式传输的功能也建立在gzip的rsyncable选项的基础之上的，不同的gzip所在操作系统或者相关的发行版不同，可能对于此选项的支持也不一定相同，所以首先需要确认所在操作系统是否支持此项设定。比如：

[root@host131 webhook]# docker exec -it gitlab_gitlab_1 sh
# cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.6 LTS"
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
# gzip --help |grep rsyncable
  --rsyncable       Make rsync-friendly archive
# 

比如CentOS 7中也是支持的

[root@host131 webhook]# cat /etc/*release*
CentOS Linux release 7.6.1810 (Core) 
Derived from Red Hat Enterprise Linux 7.6 (Source)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.6.1810 (Core) 
CentOS Linux release 7.6.1810 (Core) 
cpe:/o:centos:centos:7
[root@host131 webhook]# 
[root@host131 webhook]# gzip --help |grep rsyncable
    --rsyncable   Make rsync-friendly archive
[root@host131 webhook]# 

执行示例命令如下所示：

执行命令（GitLab 12.1之后版本）：gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes

指定备份内容

GitLab的备份中包含八个目录，如果有需要生成指定目录进行备份可以使用SKIP选项，SKIP选项字如其名，就是指定的内容不作为备份的对象目录的意思，所以可以通过取非来间接达到指定备份内容的目的。比如可以通过如下示例命令实现备份数据库和附件的之外的其他所有目录

执行命令（GitLab 12.1之后版本）：gitlab-backup create SKIP=db,uploads

另外此选项还有一个比较有用的设定，就是设定SKIP=tar，这种方式之下，就不会删除backups目录下的临时目录并生成tar文件，而是只保留备份产生的backup下面的文件目录。

Git仓库的并行备份

为了充分利用CPU，可以通过如下环境变量的设定指定Git仓库的并行备份：

• GITLAB_BACKUP_MAX_CONCURRENCY ：设定同时可以备份的最大项目个数，缺省为1
• GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY ：设定同时在不同存储上进行备份的最大项目数，缺省为1

执行命令（GitLab 12.1之后版本）：gitlab-backup create GITLAB_BACKUP_MAX_CONCURRENCY=4 GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1

备份归档文件权限

备份归档文件的权限设定可以通过/etc/gitlab/gitlab.rb中的如下选项进行设定

选项设定：gitlab_rails[‘backup_archive_permissions’] = 0644 # Makes the backup archives world-readable

本地备份归档文件保存时长

本地备份归档文件的保存时长可以通过/etc/gitlab/gitlab.rb中的如下选项进行设定

选项设定：
## Limit backup lifetime to 7 days - 604800 seconds
gitlab_rails[‘backup_keep_time’] = 604800

定时备份

可以使用crontab进行定时备份，比如每天两点进行backup

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

备份恢复：Restore

GitLab同样也提供了命令行接口用于备份恢复，需要注意的是备份和恢复需要相同的GitLab版本，比如在GitLab 12.10.5上的备份文件，恢复导入的时候还是需要导入到12.10.5版本的GitLab服务中。版本不同的话，需要先行调节GitLab版本，然后再进行备份恢复。

执行示例命令：gitlab-backup restore force=yes BACKUP=1597812374_2020_08_19_12.10.5

前提条件

执行恢复时需要手动恢复/etc/gitlab/gitlab-secrets.json文件，此文件中包含数据库加密密钥，CI/CD变量以及双因子认证等变量信息，如果在GitLab中使用到此部分内容，必须进行此文件的手动恢复。

另外从GitLab 12.9版本开始，如果存在非tar文件方式的备份（比如在备份中指定SKIP=tar），而且又没有指定BACKUP的时间戳信息，就会使用非tar文件的备份源进行恢复。

恢复选项

可以指定BACKUP和force顶选项进行恢复，简单说明如下：

• BACKUP=备份归档文件时间戳 ： 使用指定的备份归档文件进行恢复。
• force=yes ：在恢复过程中不再进行交互式询问，类似使用HereDocument缺省输入yes

执行步骤

按照如下步骤进行GitLab的备份恢复：

• 步骤1: 确保GitLab服务的启动可访问，并且版本和备份数据一致
• 步骤2: 拷贝备份文件至backups目录下，并确保权限
• 步骤3: 使用gitlab-ctl命令停止unicorn(或者puma)以及sidekiq服务
• 步骤4: 使用gitlab-backup restore进行数据恢复
• 步骤5: 手工恢复gitlab-secrets.json文件与gitlab.rb
• 步骤6: 重设、重启服务并检查

执行命令：gitlab-ctl reconfigure && gitlab-ctl restart && gitlab-rake gitlab:check SANITIZE=true

执行示例

执行示例可参看：https://liumiaocn.blog.csdn.net/article/details/107950120

参考文档

https://docs.gitlab.com/ce/raketasks/backup_restore.html