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镜像和容器的主要存储器。