翻译者：陈峻
创新式的合作开发对码农来说往往是几项繁重的“修持”任务。每个GitLab使用者都多多少少地认识到，源代码对保障DevOps项目组能无间断地开展组织工作业务流程的必要性。
有人也许会问：GitLab虽说最可信的源代码管理（SCM）工具提供网络平台之一。它会发生甚么状况呢？作为一个开放源码的发展性网络平台，GitLab无可避免甚至于受譬如：服务受阻、敲诈应用软件、和系统无法访问等各式各样潜在性严重威胁。那些有的是源于GitLab服务器受反击，有的是来自GitLab统计资料库的自身机械故障。有鉴于此，您和您的项目组应仍旧为各式各样突发性情况提早搞好准备，即：为他们的GitLab统计数据建立一个强悍的存储机制。同时，您也应当保证能将预设的存储思路，应用软件系统到他们的DevSecOps业务流程、和CI/CD管线中。
一、GitLab存储如果包涵甚么?
一旦决定了待存储的GitLab环境，他们就如果保证GitLab的存储内容包涵了各式各样GitLab存储库和元统计数据。他们能将该处的“元统计数据”，理解为针对各种类型Wiki、难题、难题注解、布署公钥、分拆允诺、LFS（Linux from Scratch，一种从网路上直接浏览源代码，一气呵成校对Linux的加装方式）、条码、Webhook、里程碑式、发布、操作等模块和各个环节的存储。只有存储好了那些，合作开发项目组和整个公司在项目中加进的所有Git存储库统计数据，才能得到充分的保护。
二、存储思路的关键优点
如果您已剖析清楚了手头上的组织工作业务流程，那么便能开始制定存储思路了。为了保证组织工作业务流程的无间断，他们如果按需展开双重存储，从而不仅可和时恢复GitLab统计数据，而且能满足审计工作、合规性、和可信性等需求。上面即是一些更为重要的可信性基本要素：
AES加密和自用的各式各样动态与静态加密公钥；
区分灵活的、长期的和无限期的保存需求；
对旧的、未使用的存储库展开归档的可行性；
通过报告和邮件通知等监控方式，来检查GitLab存储的执行情况；
对敲诈应用软件予以防护；
检查灾难恢复技术是否满足恢复目标。
上面只是与完善存储思路相关的基本安全方面。如果您想制定GitLab环境的完整存储计划，则需要考虑并构建包涵各式各样高级存储功能的替代性存储思路。
1.3-2-1存储规则
如果DevOps项目组已经为某些源代码日夜奋战了许久，那么一旦出现GitLab的受阻或存储失败，则会导致他们的成果覆水难收，同时也会让企业蒙受财务上的损失。对此，我向您介绍一个3-2-1的“黄金”备用规则。即：一家公司应当将3个存储副本保存在2个不同的存储实例中，并且至少有1个处于离线。因此，您需要注意存储复制的相关难题，以便它能协助您将本机存储的副本保存到多个位置，进而实现服务的冗余和业务的连续性。
当然，如果您的DevOps存储应用软件具有多存储兼容性的话，则能大幅节省花费在应用软件上的开销。目前，AWS S3、Backblaze B2、谷歌云存储（Google Cloud Storage）、Azure Blob Storage、GitProtect Cloud和其他任何与S3、本地或混合兼容的公有云，都能提供此类兼容性。如果您不清楚的话，请询问您的存储服务提供商，以确认是否能充分利用已有的是基础设施，将代码统计数据、连同他们的存储空间，一并存储到不同的目的地处。
2.需无限保留的统计数据
保留期限也是他们在制定存储过程中，需要重点考虑的方面。对一些非常重要的GitLab统计数据，您能将其保留期限设置为5年、10年、甚至是无限期保留。如果您的代码中包涵了个人隐私统计数据，那么其保存期限就需要满足本地的法律、法规、和共同责任的要求。
3.对敲诈应用软件的防护
存储GitLab统计数据虽说是抵御敲诈应用软件反击的最后一道防线。因此，如果您的GitLab存储方案是针对防范敲诈应用软件的话，它会在存储的过程中，对GitLab统计数据执行压缩和加密，进而保证统计数据在其存储状态是不可执行的。据此，即使您的存储统计数据被某些敲诈应用软件所截获，也不会被轻易执行或无限量地传播。此外，在最坏的情况下，就算某些敲诈应用软件能加密、修改或删除已截获到的统计数据，您手头上仍有一个存储，可方便您根据确切的时间点，恢复所需的GitLab副本，进而保证您的项目组将在毫无拖延地情况下，继续开展项目。
4.给审计工作与合规性提供监测报告
常言道：拥有信息的人正统治着世界。及时掌握任何有关GitLab存储本身、存储失败、和存储状态的信息，能协助DevOps项目组厘清他们所碰到的难题，并能对存储统计数据的可用性展开实时把控。应用软件项目项目组往往需要通过Slack通知、统计数据驱动的仪表板、电子邮件通知、和高级审计工作日志，来跟踪存储系统的每几项执行操作。此类信息不但能让您的项目组受益，而且能为审计工作和安全认证等方面，提供详细的存储完成情况的报告。
三、恢复过程应包涵哪些？
根据存储思路，对GitLab执行有效的存储，只是整个远程管理计划的一部分。他们还需要规划好能尽快恢复GitLab存储统计数据的思路。也就是说，灾难恢复计划应保证您的业务在服务受阻/无法访问、（非）故意的人为错误、和因敲诈应用软件反击而造成统计数据丢失等可能的情况下，仍能保持业务的连续性。
上面是他们在制定恢复思路时，需要仔细考虑的方面：
需要还原的统计数据所处时间点；
存储库和选定元统计数据的恢复程度与统计数据量；
用于从存储库存储统计数据展开恢复的GitLab帐户；
是否以交叉恢复的方式，从GitLab恢复到另一个Git托管网络平台（如：GitHub或Bitbucket），这在工具之间展开迁移时，非常实用；
恢复到本地设备的可能性。
在课堂教学中，如果您能将存储和恢复两项操作归并到一个应用之中的话，则能大幅节省项目组的时间。
有了恢复思路，他们在讨论面对GitLab、基础设施、和存储方案出现机械故障等场景时，咱们的项目组能如何准备：
1.GitLab出现受阻
虽然GitLab是一个可信的托管服务提供网络平台，但是发生受阻的可能性还是存在的。对此，您既能将GitLab实例以.git文件的方式，恢复到他们的计算机上；也能基于交叉恢复的方式，直接将GitLab的副本，恢复到另一个Git托管网络平台。
2.您的基础架构出现受阻
基于前文提到的3-2-1存储规则，哪怕您的基础架构出现受阻，您总会在2处目的地拥有着3个存储副本，而且其中1个处于离线状态。因此，您能从任何一个时间点获得存储副本，并轻松地恢复GitLab存储库及其元统计数据。
3.存储方案本身出现机械故障
在决定使用第三方的存储方案之前，您有必要确认其已为潜在性的受阻搞好了准备，并且能在真正发生时，为您提供适当、可信的统计数据恢复支持。例如：如果它们能与您共享在本地应用中加装的权限，那么一旦其SaaS环境出现机械故障，您便能轻松地从本地应用中，直接访问到他们的统计数据。
四、小结
综上所述，为了应对GitLab可能出现的受阻，您既能自行管理存储过程，也能编写专门的GitLab存储脚本并制作快照的命令，还能选择第三方存储应用软件的自动存储服务。同时，您需要实现设定好在灾难发生时，执行哪些恢复业务流程，让整个GitLab环境尽快可供访问，以保证项目组组织工作的连续性。
