Docker數據容器保護方式利弊
Docker 是一個非常成功的Linux開源項目。它在Linux操作系統下無需增加管理器即可虛擬化應用程序。該應用程序常被抽象地誤認為是操作系統（具有 Linux內核資源隔離功能的OS）的唯一的應用程序。換句話說，該Linux應用程序部署在Docker數據容器中，該容器能利用Linux OS 的所有功能并能隔離應用程序。
Docker容器具有移動性并且與虛擬機（VMs）相互隔離,且僅在虛擬機上進行部分操作。在深入研究Docker數據保護這個問題之前，弄清楚Docker鏡像和Docker數據容器之前的差異是十分必要的。一個Docker鏡像包括一或多個應用程序的操作系統。而Docker 容器（本文的重點）是獨立于鏡像之外的運行實例。
Docker數據容器保護機制目前十分簡單，不像VM數據保護機制那么復雜成熟。這種保護機制與VMware vSphere存儲接口數據保護、Microsoft Hyper-V Volume卷影復制服務或內核VM快照API不同。這就使得Docker容器保護機制更具有挑戰性。好消息是我們有幾種方法來實現它。
方法一：Docker內置備份和恢復機制
在備份Docker數據容器之前，容器當前狀態必須保存成Docker鏡像。該容器的運行狀態需要簡要暫停以便獲取快照，并將該鏡像重名為一個新的Docker 鏡像 --通常是基于時間線前一個鏡像的變型。將Docker容器備份當成一個鏡像在不同Docker主機系統上部署時，你要么將其推送懂啊Docker私有倉庫中要么將其保存為一個.tar文件只有這樣，該鏡像才能被移植到任一Docker主機系統上。
Docker容器的恢復取決于它的部署方式。如果鏡像被推送到Docker私有倉庫中，使用Docker命令“run”命令即可啟動一個新的容器實例。如果該鏡像存儲成一個.tar文件，該.tar備份文件必須加載到Docker主機系統的本地鏡像倉庫中然后利用“run”命令來啟動一個新的容器實例。
建立Docker備份和恢復并非自動進行。每一次都需手動進行這些備份和恢復或者寫一個腳本來實現該功能。大多數IT管理人員是采取寫腳本這一方式。盡管腳本并不復雜，但是當軟件改變或者基礎設施發生變化時，它們需要重寫。在前期以及每當生態系統變化時，記錄腳本和進行質量保證（QA）都是十分有必要的，以此防止備份和恢復故障。當質量保證團隊發現腳本的問題時，腳本需要進行修改或者重寫來糾正這些錯誤，進而保證Document升級。盡管這看起來是一個很繁瑣的過程，但這是保證Docker數據容器保護方式的關鍵。
許多IT管理員不希望面對Document、QA、故障排除或修復、修補程序和更新腳本等等麻煩，更不想手動進行所有的備份和恢復。他們更喜歡獨立、第三方支持的Docker數據保護方式。
方法二：傳統基于文件的備份和恢復
傳統的文件備份方式已流行多年，因為該方式支持多種類型的服務器、操作系統、文件系統、虛擬機管理程序、數據庫或結構化應用程序。因為該技術可同時在Linux和Window上使用，所以同樣可用于Docker數據容器上。
傳統的基于文件的備份和恢復需要一個操作系統或者是文件系統代理；一個結構化應用程序代理如關系數據庫、電子郵件等等；以及備份（即媒體）服務器。文件系統代理具有管理員權限，能夠掃描文件系統并將其備份。結構化應用代理在應用進行備份時能短暫地暫停應用。Docker容器可以看做文件系統代理 -僅是另一份需要備份的文件。如果容器中存在結構化應用程序，結構化應用程序代理必須作為Docker鏡像和運行容器的一部分安裝。
該方法存在幾個問題。代理是一個軟件，它需要不斷地運行、管理、修復、更新等等。很多代理都具有破壞性，需要操作系統重啟時進而破壞了所有的容器；而另一些在每一次部署、修復或更新時都需要應用程序重啟。這意味著它們需要預定在中斷對操作影響最少的時刻，通常是周末或者深夜。這同樣是很多的IT 公司已經使用虛擬機管理程序APIs提供的無代理備份原因。如前所述，現在不存在與Docker容器相連API。如果IT經理決定在Docker容器中不使用結構化應用程序代理，然后備份只是 crash-consistent 與application-consistent相比較了。
方法三：存儲快照
存儲快照的方式十分簡單，大多數快照消耗很少額外內存，除非需要實際地數據拷貝。然后快照被復制并移動到另一個Volume、存儲系統甚至是云存儲上。每個 volume、 LUN或文件系統中可用快照的數量--假設每一Docker數據容器--各供應商存儲系統各不相同。一些可能容納很多一些僅能容納少量快照。一個相對較新的公司Reduxio甚至可以在每次寫入上都添加時間戳然后基于這些寫操作分發一個虛擬快照，這就提供了連續快照能力。使用這些功能需要該存儲器作為Docker鏡像和容器的主要存儲器。
快照存儲的關鍵問題在于它們是crash-consistent，而非application-consistent--唯一的例外是 Reduxio。此外，許多存儲系統在給定的任一Volume、LUN或者文件系統的快照數目都有很強的限制。這就要求早期的快照需要復制下來，這就會消耗更多的存儲空間并且需要額外的存儲系統。
存儲快照經常與備份應用程序相結合以此來保持與應用程序一致性。結構化應用程序的備份代理與結構化應用同時安裝。在儲存系統獲取快照之前，該代理能暫停結構化應用，媒體備份服務器告訴存儲系統獲取快照，然后告訴該代理重啟結構化應用程序。這就提供了應用程序一致的快照，目前 Commvault、 EMC、 Hewlett Packard Enterprise、Veritas和其他幾家公司能夠提供。這種方法在管理結構化應用程序代理時仍然存在問題。
剛剛描述的組合的一個變本是復制數據管理，可由Actifio、Cohesity 和Rubrik提供。復制數據管理是在一個系統中將文件備份和存儲快照的兩者結合。這里并沒有外部媒體備份服務器。這些產品往往集中在虛擬管理程序API上。只有Actifio一個產品，存在操作系統代理可以備份 Docker容器和鏡像。但他們之中不存在任一產品同時具有結構化應用程序的一致性。
方法4：無代理的云備份和恢復
在撰寫本文的時候，只有Asigra-powered 云備份和恢復服務提供Docker數據容器和Docker 鏡像備份。該服務提供了一個 on-site物理或虛擬設備，無需代理來備份操作系統和所有的Docker 容器。最新的備份保存在本地云，該方式具有很快的回收率。此外，所有的備份都保存在云備份和恢復服務提供商的數據中心內。在第一次全卷備份后，所有的額外的備份都是永久增量，提供虛擬的、全容量的、一次性回收。所有云端備份數據刪除重復數據并對數據壓縮。
這種方法的缺點是：它必須得到云服務提供商而非軟件開發人員（盡管它可以作為一個私有許可證。）的許可。
原文鏈接： Docker data container protection methods: Pros and cons （譯者/劉崇鑫 審校/朱正貴 責編/仲浩）