共计 2966 个字符,预计需要花费 8 分钟才能阅读完成。
导读 | 面对可能出现的中断、甚至是灾难情况,本文和您讨论了制定 GitLab 备份与恢复策略的基本要点。创新式的开发对于码农来说往往是一项艰巨的“修行”任务。每个 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 环境尽快可供访问,以确保团队工作的连续性。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)