0. 摘要
雖然Docker數據容器保護方法還沒有達到基於管理程序的虛擬機的水平，但是以下這四種技術可以幫助用戶應對這一挑戰：本文介紹了Docker內置備份和恢復機制、傳統基於文件的備份和恢復、存儲快照技術、無代理的雲備份和恢復等幾種Docker容器保護機制的利弊。
1. Docker簡介
Docker是一個非常成功的Linux開源項目。它在Linux操作系統下無需增加管理器即可虛擬化應用程序。該應用程序常被抽象地誤認為是操作系統（具有Linux內核資源隔離功能的OS）的唯一的應用程序。換句話說，該Linux應用程序部署在Docker數據容器中，該容器能利用Linux OS 的所有功能並能隔離應用程序。
Docker容器具有移動性並且與虛擬機（VMs）相互隔離，且僅在虛擬機上進行部分操作。在深入研究Docker數據保護這個問題之前，弄清楚Docker鏡像和Docker數據容器之間的差異是十分必要的。一個Docker鏡像是包括一個或多個應用程序的操作系統。而Docker 容器（本文的重點）是獨立於鏡像之外的運行實例。
Docker數據容器保護機制目前十分簡單，不像虛擬機數據保護機制那么復雜成熟。這種保護機制與VMware vSphere存儲接口數據保護、Microsoft Hyper-V 卷影復制服務或內核VM快照API不同。這就使得Docker容器保護機制更具有挑戰性。好消息是我們有幾種方法來實現它。
2. Docker內置備份和恢復機制
在備份Docker數據容器之前，容器當前狀態必須保存成Docker鏡像。該容器的運行狀態需要短暫的停頓以便獲取快照，並將該鏡像重名為一個新的Docker 鏡像。該Docker 鏡像通常是基於時間線前一個鏡像的變型。將Docker容器備份當成一個鏡像在不同Docker主機系統上部署時，你要么將其推送到Docker私有倉庫中，要么將其保存為一個.tar文件。只有這樣，該鏡像才能被移植到任一Docker主機系統上。
Docker容器的恢復取決於它的部署方式。如果鏡像被推送到Docker私有倉庫中，使用Docker命令“run”命令即可啟動一個新的容器實例。如果該鏡像存儲成一個.tar文件，該.tar備份文件必須加載到Docker主機系統的本地鏡像倉庫中， 然后利用“run”命令來啟動一個新的容器實例。
內置Docker備份和恢復並非自動進行。每一次都需手動進行這些備份和恢復操作，或者寫一個腳本來實現該功能。大多數IT管理人員偏向於采取寫腳本這一方式。盡管腳本並不復雜，但是當軟件改變或者基礎設施發生變化時，腳本需要需要被重寫。為了防止備份和恢復故障，有必要對腳本進行文檔化，並在前期和生態系統發生更改時進行質量保證(QA)。當質量保證團隊發現腳本的問題時，腳本需要進行修改或者重寫來糾正這些錯誤，並且更新相關文檔。盡管這看起來是一個很繁瑣的過程，但這是保證內置Docker數據容器備份與恢復機制正常運行的關鍵。
許多IT管理員不希望面對文檔、QA、故障排除或修復、修補程序和更新腳本等等麻煩，更不想手動進行所有的備份和恢復操作。他們更喜歡獨立的、第三方支持的Docker數據保護方式。
3. 傳統基於文件的備份和恢復方式
傳統的文件備份方式已流行多年，因為該方式支持多種類型的服務器、操作系統、文件系統、虛擬機管理程序、數據庫或結構化應用程序。因為該技術可同時在Linux和Window操作系統層面使用，所以同樣可用於Docker數據容器的保護上。
傳統基於文件的備份和恢復需要一個操作系統或文件系統代理、一個結構化應用程序代理（如關系型數據庫、電子郵件等等）和備份（即介質，用於存放備份數據）服務器。文件系統代理必須具有管理員權限，能夠掃描文件系統並將其備份；結構化應用代理用於處理備份過程中的應用一致性問題（如在應用進行備份時短暫地暫停應用）。Docker容器在文件系統代理看來只是要備份的另一組文件。如果容器中存在結構化應用程序，結構化應用程序代理必須作為Docker鏡像和運行容器的一部分安裝。
該方法存在幾個問題。代理程序作為軟件的一部分，它需要考慮部署、管理、更新、升級等繁瑣的問題。很多代理都具有破壞性，需要操作系統重啟時進而破壞了所有的容器；而另一些代理程序在每一次部署、修復或更新時都需要應用程序重啟。這意味着它們需要預約對系統運營影響最小的時刻，通常是周末或者深夜。這同樣是很多的IT公司選擇無代理備份原因（如虛擬機管理程序APIs等）。然而，當前並不存在與Docker容器相關API，滿足Docker數據容器無代理備份與恢復技術方案的要求。如果IT管理員決定在Docker容器中不使用結構化應用程序代理，則不能有效的保證Docker數據容器備份集的應用一致性，可能存在恢復Docker數據容器備份數據時內部結構化應用程序無法正常運行的風險。
4. 存儲快照技術
存儲快照使用起來非常簡單，並且除觸發實際數據拷貝操作外，大多數快照幾乎無需消耗額外的存儲空間。然后快照被復制並移動到另一個卷、存儲系統或是雲存儲上。每個卷、LUN（邏輯存儲單元）或文件系統中可用快照的數量（假設每一個Docker數據容器存放在獨立的卷、LUN或文件系統上）由底層存儲廠商決定。各家廠商的存儲系統提供的快照能力各不相同，部分存儲廠商能夠支持很多快照，而其他廠商僅能支持少量快照。一家新興技術公司Reduxio甚至可以在每次I/O寫入上都添加時間戳，然后基於這些寫操作分發一個虛擬快照，這就提供了連續快照能力。使用存儲快照技術保護Docker數據容器需要Docker鏡像和容器的主存儲支持該功能。
存儲快照的關鍵問題在於它們是crash-consistent（崩潰一致性，生成的Docker數據容器備份集執行恢復操作時內部運行的應用程序數據損壞），而非application-consistent（應用一致性），唯一的例外是Reduxio。此外，許多存儲系統在給定的任一卷、LUN或文件系統的快照數目都有明確的數量限制。這就要求之前的的快照需要復制下來，這就會消耗更多的存儲空間並且需要額外的存儲系統。
存儲快照技術經常與備份應用程序相結合以此來保證應用一致性。結構化應用程序的備份代理與結構化應用同時安裝。在儲存系統獲取快照之前，該代理能暫停結構化應用，備份服務器通知存儲系統對相關卷、LUN或者文件系統執行快照，然后在通知應用程序代理重啟結構化應用程序。這就提供了應用程序一致性的快照，目前 Commvault、 EMC、 Hewlett Packard Enterprise、Veritas和其他幾家公司采用了該方式實現。這種方法在管理結構化應用程序代理時仍然存在問題。
存儲快照技術與備份應用程序代理結合的另外一種方式是CDM（復制數據管理），目前主要有Actifio、Cohesity 和Rubrik提供基於該技術實現的產品。復制數據管理技術是在一個系統中將文件備份和存儲快照兩者結合。這里並沒有外部備份服務器。這些產品往往集中在虛擬管理程序API上。只有Actifio提供的產品，存在操作系統層面的備份代理，可以備份Docker容器和鏡像。但他們之中任何一家的產品都不具備能夠保證結構化應用程序一致性的能力。
5. 無代理的雲備份和恢復技術
在撰寫本文的時候，只有Asigra-powered雲備份和恢復服務提供Docker數據容器和Docker鏡像備份。該服務提供了一個on-site物理或虛擬設備，無需代理來備份操作系統和所有的Docker容器。最近的備份數據保存在本地的雲設備中，以便更快地恢復。此外，所有的備份數據都保存在雲備份和恢復服務提供商的數據中心內。在第一次全量備份后，后續所有的備份都是永久增量（只備份自上一次備份操作執行后變化的數據），提供虛擬的、全量恢復、增量恢復。所有存儲在雲端的備份數據都經過了重刪和壓縮處理，以高效利用存儲空間。
這種方法的缺點是：它必須得到雲服務提供商而非軟件開發人員（盡管它可以作為一個私有許可證。）的許可。
附：參考文檔