编者按：这个系列分为四个部分，本文是第一部分。该系列将对部署在重复数据删除解决方案上的技术和实施策略进行探讨。
第一部分将讨论重复数据删除的基本位置–独立设备、VTL（虚拟磁带库）解决方案或主机上的软件。
第二部分将讨论重复数据删除的时机，也指在线处理和后处理之争。
第三部分将讨论统一的重复数据删除和独立的重复数据删除，探讨两种不同方式的各自优势并进行对比：使用单一厂商的产品，并用同样的解决方案来处理所有次级数据；对不同类型的数据部署唯一的重复数据删除方案。
第四部分将讨论性能问题。许多重复数据删除厂商将它们系统的数据处理速率夸大到难以置信的地步，我们将探讨如何辨别这些声明。
重复数据删除市场的最初产品是基于特定的系统，专注于提升磁盘到磁盘备份解决方案的效能，并帮助组织减少它们对磁带的依赖。
随着重复数据删除解决方案逐渐流行，一些主存储厂商开始尝试将该技术作为一种附加功能加在它们的产品上，最主要的就是虚拟磁带库产品。备份软件厂商也开始将该功能加到它们的解决方案上。现在，由于IT管理者们可以得到许多重复数据删除功能，因此新问题就是，重复数据删除流程应该放在哪里才是最好的？
在你阅读的过程中，要记住，重复数据删除的主要关注点是次级存储–归档和备份，而不是主存储。同时还要注意的是重复数据可能一开始很不明显。例如，一个Oracle数据库可以用几种不同方式备份–使用内置的RMAN工具；使用一个组织的企业级备份软件；或者使用专门针对Oracle的备份工具。所有这些方式都会产生自己的数据集。由于这些数据集是同一个Oracle数据库的备份，因此每个数据集内的数据基本上都是相同的。
通用型重复数据删除系统
包括Data Domain和昆腾在内的几家厂商提供不和特定虚拟磁带库或备份设备相联系的重复数据删除产品。这些设备可以被称为通用型重复数据删除系统。
使用通用型重复数据删除存储系统的好处就是它就是为删除重复数据而设计的。因此，这些系统对数据来源是中立的，也就是说来源的备份数据可以来自多个不同的应用（备份软件、应用程序工具、归档应用程序或直接来自用户）。
通用型系统能够提供多种数据访问协议（NFS：网络文件系统，CIFS：通用网际文家系统，或磁带仿真），并提供多种不同类型的物理连接（以太网或光纤通道）。在真实世界的数据中心中，有许多不同来源的备份数据，保持来源中立能够带来显而易见的好处。
虽然在通用系统中的数据输入可以是来自多个来源，但是数据的重复数据删除流程却是在所有来源都可以进行的。例如，管理者可以通过备份应用程序将微软的SQL环境备份到一个通用型重复数据删除系统。然后，同样的数据可以被放入SQL DBA的重复数据删除系统。之后，通过使用VMware备份工具，该数据还可以被捕获为VMware镜像的一部分并移入重复数据删除系统。
在上述例子中，所有的数据都是类似的，而且在数据被存储之前，来自每个来源的冗余部分都会被删除。注意这个例子是针对每天都有微小变化的文件。这种多保护模式在今天的数据中心并不少见，因此，按周看或是按月看，空间节省可能都会有所变化。
通用型重复数据删除系统一般能够（或者说应该能够）进行在线重复数据删除，因为一般来说，这是最有效率的流程方式。理想情况下，重复数据删除系统还应该能够辨别长度可变的数据部分，这样能够提供最有效的重复数据删除效果。例如，它应该能够只鉴别和存储数据库的可变部分，而不是将整个文件都放在每个备份中。
最近，包含复制功能的通用重复数据删除系统为用户提供了将备份数据复制到远程站点上的最佳方式。通过使用重复数据删除，重复数据删除系统只需要在网络上复制新的数据部分就可以了。
最有效率的系统将是能够在多个站点上通过在线处理进行重复数据删除方式下的复制的系统。目前为止，Data Domain符合这个要求。此外，在线的重复数据删除能够在系统开始接收数据的时候就开始进行复制流程。这和虚拟磁带库系统不同，后者一般使用后处理方式的重复数据删除，因此复制流程只能稍后进行–因此其灾难恢复数据可能就有风险。
虚拟磁带库解决方案
虚拟磁带库的提供厂商，例如FalconStor（它也提供给EMC和Sun），NetApp和Sepaton，一般都会认证一系列的备份应用程序，但是它们不能对数据来源或数据目标保持中立。
特别需要指出的是，虚拟磁带库解决方案是仿真磁带库。因此，只有那些对磁带库具有特定支持的应用程序才可以使用虚拟磁带库，使得应用程序本身受到限制。
在数据中心中流行使用的许多工具一般都是将数据放入磁盘，而并不支持磁带协议。许多数据保护工具不支持将数据复制到虚拟磁带库。
对带重复数据删除功能的虚拟磁带库的局限的考虑主要集中在该系统所带来的管理上的复杂性以及在线处理和后处理的优劣之争上。一般来说，新增的虚拟磁带管理需要在磁盘上仿真磁带，因此对已经很复杂的环境来说不异于又增加了更多的复杂性。
对持续性的每日管理来说，后处理方式增加了复杂性，而且这种方式对重复数据删除的时间以及复制（或创建灾难恢复副本）的时间都会有负面的影响。后处理方式同时还要求增加额外的磁盘容量来作为重复数据删除的"着陆区"。
最终，更多的容量意味着需要管理更多的磁盘，消耗更多的能源和冷却成本，使用更多的空间，当然，还要购买更多的设备。由于其使用低效率的后处理重复数据删除方式，因此现有的虚拟磁带库产品比较少加上重复数据删除功能的。
基于软件的重复数据删除和单实例存储
如人们所期望的那样，备份软件厂商现在在它们的功能集上也增加了重复数据删除功能。此外，诸如CommVault这样的备份软件厂商正在使用一种被称为单实例的数据缩减技术，在备份主机接收到数据并开始文件层次的比较的时候，该技术就开始发挥作用。
虽然这种方式确实能够减少一些由于备份流程所引起的存储需求，但是它不能解决网络带宽要求的问题，它也不能解决类似数据的多个副本的问题（只有通过某一特定应用程序的数据才会被进行冗余比较）。
单实例存储并不能解决备份存储中的其他重要问题–那些定期发生轻微变化的文件。
在单实例存储中，那些每天无变化的离散文件一般会被"实例到备份之外"。但是，在任何一个备份传送策略中，那些无变化的文件并不是问题所在，那些每天变化一点的大型文件才是问题。
数据库，VMware镜像和Exchange存储经常每天都会发生轻微变化。一个文件层次的单实例比较可能会把数据变化看成不同文件，而不是看成同一文件的不同变化。这也就是说整个文件都会被重新存储。和真正的重复数据删除技术比起来，这种结果导致数据缩减的效果苍白无力。很清楚，如果没有数据块级别的缩减，就不会有空间节省，对数据库这种可能非常大型的文件来说尤其如此。
单实例存储的另一个不能解决的问题就是，类似数据集经常有多个备份来源。例如，备份管理员可能会用备份软件的Exchange模块来备份Exchange；而Exchange管理员可能同时也用另一个工具来备份Exchange存储。这里没有数据删减，因为一个备份软件不能看到由另一个独立工具所创建的备份。
在这两种情况下（经常性变化且小规模变化的应用，以及多备份来源），即使备份来源（备份应用程序或Exchange工具）是不同的，一个在数据块级别上进行重复数据删除的系统也能够识别出冗余数据块，并且减少存储负担。
使用单实例技术的软件提供商声称这种存储方式是最适合存储恢复的方式，言外之意是重复数据删除系统有一些恢复上的性能问题。虽然一些厂商的重复数据删除系统可能是有一些恢复性能问题，但是只要系统的架构设计得当，那么重复数据删除流程不会给性能造成很大的影响。
在真实世界的数据中心里，在通过通用型重复数据删除系统进行恢复的过程中，备份后数据和来源服务器之间有太多的其他瓶颈。如果恢复的性能要求超过了从磁盘恢复的能力，那么就需要考虑其他的高可靠性解决方案，例如集群技术或有源目标（有源目标是一种备份目标应用程序，可以像一个正常的文件系统那样被浏览和阅读访问）。
最后，使用单实例技术的方式的前提假设是使用单一的软件应用程序来进行所有类型数据的所有的备份、归档和其他数据管理功能。这是不切实际的。虽然许多备份软件厂商确实提供备份以外的某种形式的额外组件，但是这些额外模块之间的功能性有所不同，而且实际上大部分客户在归档和备份上是分别使用不同的解决方案，在特定平台上（如VMware）使用特定应用程序。而且一个软件制造商为一个针对唯一的数据库或操作系统的模块所投入的时间和成本也是有限的。
小结
数据来源中立、协议/连接性中立、数据类型中立，这些通用型重复数据删除系统的功能是进行备份存储和归档数据存储的最好工具。注意：不要被内置于你的备份软件中的重复数据删除模块的特定功能所局限，不要被虚拟磁带库中只能适用于磁带的协议所局限。
