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 （译者/刘崇鑫 审校/朱正贵 责编/仲浩）