譯者 | 陳峻
審校 | 孫淑娟
創新式的開發對于碼農來說往往是一項艱巨的“修行”任務。每個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環境盡快可供訪問，以確保團隊工作的連續性。
原文鏈接：https://dzone.com/articles/devops-security-which-gitlab-backup-best-practices
譯者介紹：
陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。?
