几种常见的Docker数据容器保护方式利与弊
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容器。最近的备份数据保存在本地的云设备中，以便更快地恢复。此外，所有的备份数据都保存在云备份和恢复服务提供商的数据中心内。在第一次全量备份后，后续所有的备份都是永久增量（只备份自上一次备份操作执行后变化的数据），提供虚拟的、全量恢复、增量恢复。所有存储在云端的备份数据都经过了重删和压缩处理，以高效利用存储空间。
这种方法的缺点是：它必须得到云服务提供商而非软件开发人员（尽管它可以作为一个私有许可证。）的许可。
附：参考文档
