服务中断、系统宕机…GitLab崩了怎么办？

共计 2966 个字符，预计需要花费 8 分钟才能阅读完成。

有人也许会问：GitLab 可谓最可靠的源代码管理（SCM）工具提供平台之一。它会发生什么状况呢？作为一个开源的开放性平台，GitLab 不可避免地会受到诸如：服务中断、勒索软件、以及系统宕机等各种潜在威胁。这些有的源自 GitLab 服务器受到攻击，有的来自 GitLab 数据库的自身故障。为此，您和您的团队应始终为各种灾难情况提前做好准备，即：为自己的 GitLab 数据建立一个强大的备份机制。同时，您也应当保证能够将默认的备份策略，集成到自己的 DevSecOps 流程、以及 CI/CD 管道中。

一旦决定了待备份的 GitLab 环境，我们就应该确保 GitLab 的备份内容包含了各种 GitLab 存储库和元数据。我们可以将此处的“元数据”，理解为针对各类 Wiki、问题、问题注释、部署密钥、合并请求、LFS（译者注：Linux from Scratch，一种从网上直接下载源码，从头编译 Linux 的安装方式）、标签、Webhook、标签、里程碑、发布、操作等组件和环节的备份。只有备份好了这些，开发团队和整个公司在项目中用到的所有 Git 存储库数据，才能得到充分的保护。

如果您已梳理清楚了手头的工作流程，那么便可以开始制定备份策略了。为了确保工作流程的不间断，我们应该按需进行多重备份，从而不仅可以及时恢复 GitLab 数据，而且能够满足审计、合规、以及安全性等需求。下面便是一些值得注意的安全性要素：

1. AES 加密、以及自用的各种动态与静态加密密钥；
2. 区分灵活的、长期的、以及无限期的保存需求；
3. 对旧的、未使用的存储库进行归档的可行性；
4. 通过报告和邮件通知等监控方式，来检查 GitLab 备份的执行情况；
5. 对勒索软件予以防护；
6. 检查灾难恢复技术是否满足恢复目标。

上面只是与完善备份策略相关的基本安全方面。如果您想制定 GitLab 环境的完整备份计划，则需要考虑并构建包含各种高级备份功能的替代性备份策略。

如果 DevOps 团队已经为某些源代码日夜奋战了许久，那么一旦出现 GitLab 的中断或备份失败，则会导致他们的成果覆水难收，同时也会让企业蒙受财务上的损失。对此，我向您介绍一个 3 -2- 1 的“黄金”备用规则。即：一家公司应当将 3 个备份副本保存在 2 个不同的存储实例中，并且至少有 1 个处于离线。因此，您需要注意备份复制的相关问题，以便它能够协助您将本机备份的副本保存到多个位置，进而实现服务的冗余和业务的连续性。

当然，如果您的 DevOps 备份软件具有多存储兼容性的话，则可以大幅节省花费在软件上的开销。目前，AWS S3、Backblaze B2、谷歌云存储（Google Cloud Storage）、Azure Blob Storage、GitProtect Cloud、以及其他任何与 S3、本地或混合兼容的公有云，都可以提供此类兼容性。如果您不清楚的话，请询问您的备份服务提供商，以确认是否可以充分利用已有的基础设施，将代码数据、连同自己的存储空间，一并备份到不同的目的地处。

保留期限也是我们在制定备份过程中，需要重点考虑的方面。对于一些非常重要的 GitLab 数据，您可以将其保留期限设置为 5 年、10 年、甚至是无限期保留。如果您的代码中包含了个人隐私数据，那么其保存期限就需要满足本地的法律、法规、以及共同责任的要求。

备份 GitLab 数据可谓抵御勒索软件攻击的最后一道防线。因此，如果您的 GitLab 备份方案是针对防范勒索软件的话，它会在备份的过程中，对 GitLab 数据执行压缩和加密，进而保证数据在其存储状态是不可执行的。据此，即使您的备份数据被某些勒索软件所截获，也不会被轻易执行或无限量地传播。此外，在最坏的情况下，就算某些勒索软件可以加密、修改或删除已截获到的数据，您手头仍有一个备份，可方便您根据确切的时间点，恢复所需的 GitLab 副本，进而保证您的团队将在毫无拖延地情况下，继续开展项目。

常言道：拥有信息的人正统治着世界。及时掌握任何有关 GitLab 备份本身、备份失败、以及备份状态的信息，可以协助 DevOps 团队厘清他们所碰到的问题，并能够对备份数据的可用性进行实时把控。软件项目团队往往需要通过 Slack 通知、数据驱动的仪表板、电子邮件通知、以及高级审计日志，来跟踪备份系统的每一项执行操作。此类信息不但能够让您的团队受益，而且可以为审计和安全认证等方面，提供详细的备份完成情况的报告。

根据备份策略，对 GitLab 执行有效的备份，只是整个灾备计划的一部分。我们还需要规划好能够尽快恢复 GitLab 备份数据的策略。也就是说，灾难恢复计划应确保您的业务在服务中断 / 宕机、（非）故意的人为错误、以及因勒索软件攻击而造成数据丢失等可能的情况下，仍能保持业务的连续性。

下面是我们在制定恢复策略时，需要仔细考虑的方面：

1. 需要还原的数据所处时间点。
2. 存储库和选定元数据的恢复程度与数据量。
3. 用于从存储库备份数据进行恢复的 GitLab 帐户。
4. 是否以交叉恢复的方式，从 GitLab 恢复到另一个 Git 托管平台（如：GitHub 或 Bitbucket），这在工具之间进行迁移时，非常实用。
5. 恢复到本地设备的可能性。

在实践中，如果您可以将备份和恢复两项操作归并到一个应用之中的话，则可以大幅节省团队的时间。有了恢复策略，我们在讨论面对 GitLab、基础设施、以及备份方案出现故障等场景时，咱们的团队能够如何准备：

虽然 GitLab 是一个可靠的托管服务提供平台，但是发生中断的可能性还是存在的。对此，您既可以将 GitLab 实例以.git 文件的方式，恢复到自己的计算机上；也可以基于交叉恢复的方式，直接将 GitLab 的副本，恢复到另一个 Git 托管平台。

基于前文提到的 3 -2- 1 备份规则，哪怕您的基础架构出现中断，您总会在 2 处目的地拥有着 3 个备份副本，而且其中 1 个处于离线状态。因此，您可以从任何一个时间点获得备份副本，并轻松地恢复 GitLab 存储库及其元数据。

在决定使用第三方的备份方案之前，您有必要确认其已为潜在的中断做好了准备，并且可以在真正发生时，为您提供适当、可靠的数据恢复支持。例如：如果它们能够与您共享在本地应用中安装的权限，那么一旦其 SaaS 环境出现故障，您便可以轻松地从本地应用中，直接访问到自己的数据。

综上所述，为了应对 GitLab 可能出现的中断，您既可以自行管理备份过程，也可以编写专门的 GitLab 备份脚本并制作快照的命令，还可以选择第三方备份软件的自动备份服务。同时，您需要实现设定好在灾难发生时，执行哪些恢复流程，让整个 GitLab 环境尽快可供访问，以确保团队工作的连续性。

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券