应遵循哪些 GitLab 备份最佳实践

创造新的和独特的东西是一项艰巨的任务。如果将其与开发过程相乘，每个 GitLab 用户都会明白保护源代码是一项要求最高但最具挑战性的任务。那么，保护DevOps团队工作的最佳方式是什么？找到开发工作流在任何情况下都不会中断或丢失的平衡和保证。

有人可能会问：“ GitLab会发生什么？它是最可靠的源代码管理 (SCM) 工具提供商之一”是的，是的。不幸的是，存在许多威胁，例如中断、勒索软件和停机——想象一下，即使是整个 GitLab 服务器或 GitLab 数据库也可能出现故障。因此，您和您的团队应该随时为任何灾难场景做好准备。如何？最好的方法是为你的 GitLab 数据建立一个强大的备份策略。此外，将默认备份策略集成到您的DevSecOps流程和 CI/CD 管道中是个好主意。

GitLab 备份应该包含什么？
一旦您决定备份您的 GitLab 环境，您应该确保您的 GitLab 备份包括 GitLab 存储库和元数据。在“元数据”下，我们理解它应该包括 Wiki、问题、问题评论、部署密钥、合并请求、LFS、标签、webhooks、标签、里程碑、发布、操作等的备份。只有在这种情况下，团队的开发人员和整个公司将完全保证他们的备份过程是正确的，并且他们所有的 git 存储库数据都得到了很好的保护。

完美备份策略的关键特性
如果工作流程组织得当，那就太好了。关于备份过程也可以这样说。为了确保工作流程中断，应该有可能进行多个备份，不仅可以恢复 GitLab 数据，还可以满足审计、合规性和安全性需求。因此，值得牢记的安全问题如下：

AES 加密和您自己的加密密钥，飞行中和静态加密；
灵活、长期、无限保留；
存档旧的、未使用的存储库的可能性；
监控机会以查看 GitLab 备份是如何执行的（报告、电子邮件通知等）；
勒索软件保护；
灾难恢复技术和许多恢复目的地。
虽然，这里只提到了用于完善备份过程的基本备份功能。如果您想掌握 GitLab 环境的备份计划，值得考虑并构建替代备份策略，其中包括高级备份功能。

3-2-1 备份规则
当一个 DevOps 团队长期致力于源代码，但由于备份失败而突然因灾难而丢失数据时，这是难以想象的损失（也是财务损失）。因此，始终值得遵循“黄金”标准——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 帐户，
交叉恢复到另一个 Git 托管平台，例如，从 GitLab 到 GitHub 或 Bitbucket（这在工具之间迁移时基本上非常有用）
恢复到本地设备的可能性。
此外，提前考虑当 GitLab、您的基础设施或您的备份解决方案出现故障时您和您的团队将做什么总是一个好主意。那么，让我们看看这些场景。

场景 1. GitLab 宕机
Gitlab 是可靠的托管服务提供商，但有时会发生中断。在这种情况下，要为您的团队提供不间断的工作，您可以将本地机器（GitLab 实例）作为 .git 文件还原到您的计算机，或者您可以将 GitLab 副本还原到另一个 git 托管平台（如果您有交叉恢复）。而已！您的备份任务已完成。

场景 2. 您的基础架构出现故障
如果您将 3-2-1 备份规则应用于您的 GitLab 存储库和元数据，您的备份解决方案可以轻松解决这一挑战。然后，您总是在 2 个目的地有 3 个副本，其中一个在异地。而已！您可以从任何时间点运行备份副本。

场景 3. 您的备份解决方案已关闭
一旦您决定使用第三方备份解决方案，有必要确保您的备份提供商已准备好应对潜在的中断情况，并可以在停机时为您提供适当可靠的数据恢复技术。例如，它可以与您共享本地应用程序的安装程序。在这种情况下，如果其 SaaS 环境出现故障，您可以轻松地从该本地应用程序访问您的数据。 

结论
备份过程的外观由公司决定 - 如果他们想自己管理备份过程，他们可以编写 GitLab 备份脚本或使用一些命令制作快照，或者他们可以选择第三方备份软件将为他们做自动备份。他们应该记住的一件事是，他们需要执行哪些备份恢复程序才能在发生灾难时访问整个 GitLab 环境。答案是专业的备份解决方案，不仅可以帮助您轻松设置备份计划，还可以确保您的副本可以立即恢复，以确保您团队的工作连续性。