如何备份你的GitLab服务器

使用自我管理的GitLab实例的组织通常依赖它来保存源代码、项目管理和操作工具。有一个有效的备份是至关重要的，这样你的数据就能在硬件故障、服务器更新失败或恶意泄露的情况下得到保护。

GitLab有一个内置的备份组件，可以为您的安装数据创建一个完整的存档。存档可以在运行相同GitLab版本的新服务器上恢复。

下面介绍如何将备份设置为本地文件系统或Amazon S3存储桶。这些步骤用于GitLab综合版本。如果您的实例是从源代码构建的，则需要修改GitLab CLI命令，在它们前面加上bundle exec rake。

按需备份

创建备份的最简单方法是使用按需创建命令。在shell中运行以下命令:

sudo gitlab-backup create

这适用于GitLab 12.2和更新版本。旧版本应该使用替代版本:

sudo gitlab-rake gitlab:backup:create

备份将作为tar存档保存在GitLab配置文件定义的目录中。Omnibus安装默认使用/var/opt/gitlab/backups。每个备份存档都以其创建时间戳和GitLab版本命名。

备份包括什么?

GitLab的内置备份实用程序导出用户在GitLab实例上创建的数据。这包括GitLab数据库和磁盘上的Git存储库中的所有内容。

恢复备份将恢复您的项目、组、用户、问题、上传的文件附件和CI/CD作业日志。备份还包括上传到集成容器注册表的GitLab Pages网站和Docker映像。

不支持添加到GitLab的包注册表中的包。如果您需要在不需要手动重新构建的情况下恢复包，则应该配置安装以将包保存到外部对象存储提供程序。

创建备份计划

没有集成的机制来定义自动备份计划。您应该设置自己的cron任务来运行上面显示的备份命令。

执行sudo crontab -e命令打开root用户的crontab，在文件中添加如下内容:

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

保存并关闭文件以应用crontab更改。这个例子将在每天晚上9点创建一个新的备份。设置CRON环境变量指示GitLab隐藏备份进度显示，这样您就不会收到带有作业输出的冗余CRON电子邮件。

按原样使用此任务将无限期地保留每个备份，直到手动清理它们。如果您正在运行一个包含大型项目的活动GitLab实例，那么这会快速消耗大量存储空间。

一个可选的配置键允许您删除旧的存档，作为备份创建脚本的一部分。打开GitLab配置文件/etc/gitlab/gitlab.rb搜索backup_keep_time，取消该行注释，并设置希望保留每个备份的秒数。

gitlab_rails['backup_keep_time'] = 432000

这里的备份将保留5天。每次执行备份创建命令时，GitLab都会删除备份目录中所有符合条件的存档。

当配置文件更改时，您需要重新配置GitLab。运行sudo gitlab-ctl reconfigure应用新设置。

排除数据类型

有时，您可能希望使用受支持数据类型的子集运行备份。定义SKIP环境变量可以让您排除特定的操作，从而精简最终的存档。

环境变量接受一个以逗号分隔的数据类型列表。您可以在GitLab wiki中找到当前支持的选项。

以下是如何备份除容器注册表映像之外的所有内容:

sudo gitlab-backup create SKIP=registry

排除注册表内容通常是显著降低备份大小和加快其创建速度的简单方法。如果一个团队有几个活跃的项目，每天构建多个Docker映像，那么很快就会积累千兆字节的注册表数据。将它们从备份中排除并不一定是太大的风险，因为您总是可以使用存储库中的Dockerfile重新构建映像。

备份到S3

GitLab可以自动将备份保存到s3兼容的对象存储提供商。取消backup_upload_connection行注释，并添加连接详细信息:

gitlab_rails['backup_upload_connection'] = {
    "provider" => "AWS",
    "region" => "eu-west-1",
    "aws_access_key_id" => "access_key",
    "aws_secret_access_key" => "secret_key",
    # "endpoint" => "https://..."
}

添加您自己的访问密钥、秘密密钥和AWS区域ID以完成连接。如果连接到AWS以外的提供商，也应该设置端点字段。提供对象存储服务器的URL，以便GitLab可以上传。

您还必须设置backup_upload_remote_directory键。在配置文件中找到这一行，取消注释，并设置一个S3桶名称，将备份上传到:

gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups';

运行sudo gitlab-ctl reconfigure来应用您的更改。

备份创建命令现在将其存档上传到配置的S3桶。通过将备份存储在异地，这为您提供了更大的冗余，保护您免受物理硬件故障的影响。

注意，使用S3存储时不支持backup_keep_time设置。仅适用于本地存储的备份归档。您可以通过使用S3内置的过期策略来实现类似的功能，该策略在设定的时间段过后自动删除上传。

复制备份策略

GitLab的默认备份策略是将数据连续流到tar存档。这通常工作得很好，但在非常活跃的GitLab实例上可能会出现问题。在数据到达归档之前，源目录中的数据可能会发生变化，导致tar在读取文件时跳过它并更改文件。

为了解决这个问题，GitLab引入了一个可选的拷贝策略。这会将所有符合条件的备份数据复制到一个临时目录，然后将复制的内容流到最终的tar归档文件中。这确保了tar不会从活动的GitLab实例中读取数据，但也有暂时增加GitLab存储消耗的副作用。备份性能也会受到明显的影响，尤其是在速度较慢的存储设备上。

执行backup命令时，通过设置环境变量strategy激活拷贝策略。您应该确保有足够的可用磁盘空间。GitLab将在数据类型阶段运行备份，因此您只需将最大数据类型的大小增加一倍即可。例如，如果您有5GB的Git存储库和10GB的容器注册表，那么您需要额外的10GB可用空间，而不是15GB。

sudo gitlab-backup create STRATEGY=copy

别忘了:备份你的配置文件!

GitLab的备份脚本只管理用户创建的数据。还有另外两个对GitLab服务器的操作至关重要的文件。这些也必须备份，以确保实例的成功恢复。

• /etc/gitlab/gitlab.rb – 这是你的GitLab配置文件。除了最基本的安装之外，所有的安装通常都会随着时间的推移进行许多修改。备份此文件可以让您将其放入新的GitLab安装中，而不必从头开始。
• /etc/gitlab/gitlab-secrets.json – 该文件必须备份。它包括数据库加密密钥、用于双因素身份验证的秘密以及其他不可恢复的敏感数据。该文件放置不当可能导致任何恢复工作都无法进行，即使您有可用的可用备份存档。

您可以使用另一个cron任务来备份这两个文件。它们应该从服务器上复制下来，这样在遇到硬件故障时仍然可以访问它们。

结论

备份对于任何GitLab管理员都是至关重要的。软件通常对组织中的每个团队都至关重要，因此任何意外停机都可能导致严重的操作挑战。

GitLab提供了常规备份所需的一切。最好的方法是创建一个定期运行内置脚本的cron任务。将备份档案保存到外部对象存储，以防止硬件丢失、故障或损坏。记得手动备份你的GitLab配置和秘密文件，否则恢复过程将会非常复杂。

原文