译者 | 陈峻

审校 | 孙淑娟

创新式的开发对于码农来说往往是一项艰巨的“修行”任务。每个GitLab用户都或多或少地认识到，源代码对于保障DevOps团队能够不间断地开展工作流程的重要性。

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

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

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

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

上面只是与完善备份策略相关的基本安全方面。如果您想制定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备份数据的策略。也就是说，灾难恢复计划应确保您的业务在服务中断/宕机、（非）故意的人为错误、以及因勒索软件攻击而造成数据丢失等可能的情况下，仍能保持业务的连续性。

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

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

在实践中，如果您可以将备份和恢复两项操作归并到一个应用之中的话，则可以大幅节省团队的时间。

有了恢复策略，我们在讨论面对GitLab、基础设施、以及备份方案出现故障等场景时，咱们的团队能够如何准备：

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

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

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

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

原文链接：//dzone.com/articles/devops-security-which-gitlab-backup-best-practices

陈峻 （Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验。​

原文来自：

本文地址：//gulass.cn/when-gitlab-cruash.html编辑：清蒸github，审核员：清蒸github

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：