重复数据删除技术生存指南（第二篇）

时机问题

现在重复数据删除领域最热门的话题之一就是应该在什么时候启动重复数据删除流程？应该选择在数据传送的过程中进行处理的in-line方式还是选择在完成备份之后进行处理的post-process呢？

在上一篇文章中我们已经谈到了关于重复数据删除更为详尽的解释，这里我们快速回顾一下，重复数据删除是一个将输入数据流与之前保存在系统中的数据进行比较、找出冗余的子文件信息、只保存一个版本的文件信息的流程。在备份过程中这项技术非常有价值，因为大多数的数据都是相同的，尤其是从完全备份到完全备份。

重复数据删除技术的发生时间有三种：inline、post-processing以及两者的结合体。

如果一款产品是inline重复数据删除产品，这就是说在应用接收数据的时候，如果冗余数据是相同的，那么就创建一个指针，只有唯一的数据被写入磁盘——重复数据永远不会被写入到磁盘中。Post-processing是指所有数据以最初的格式第一次被写入到磁盘，然后一个独立的、连续的流程对这些数据进行分析，将重复数据删除掉。一些厂商推出了不同版本的Post-processing重复数据删除产品，利用缓存来在整个本分完成数据接收之前启动 post-processing流程。

状态问题

inline系统一个最大有点就是状态的简化。你只需要在一种状态下处理数据，无论怎样，数据总是被重复数据删除掉的。而post-processing在状态方面存在一些缺点：你必须在原始或者已经被重复删除的状态下处理数据。没有足够的原始空间来支持备份流程。

厂商已经通过要求用户管理这两种备份池或者让系统来管理基础数据的方法解决这个问题。不管选择哪种方法，你都是需要做一些管理工作来确保有足够的空间来支持整个备份流程的。这并不是说inline系统就不能对糟糕的容量计划或者不可预测的环境变更有“免疫功能”。根据我们的经验来看，用户管理 inline系统相对来说更为轻松一些。

性能问题

对inline系统来说，性能可以说是它的一个软肋，因为你可能需要牺牲性能来获得交互的简化性。实时重复数据删除需要具有一定的能力，功能不足或者系统效率过低都有可能使inline系统无法接收数据。而对于Post-processing系统来说，我们就不必担心重复数据造成的接收性能影响，因为post-processing不需要在接收数据的过程中对其进行处理。磁盘或者网络I/O限制都可能是造成性能瓶颈的根源。inline系统依赖于处理减速的成本以及能源增加的速度，这就是所谓的摩尔定律。这就导致了inline系统可以接收数据的速度持续增长，现在，一个中端或者高端的inline 系统每小时可以处理大约750GB～1TB的数据。

备份流程所需的性能是作出重复数据删除决策一个关键因素。如果你通过每小时传输1TB数据来满足备份窗口的要求，或者如果你的基础架构无法保持每小时传输1TB数据的话，那么inline系统的易用性特点就掩盖住了post-processing系统尚未实现的性能水平。

如果它允许你满足备份窗口的话，就无法支持多个这样的系统。这一点很重要，因为到目前为止没有哪个系统可以在独立的应用之间支持重复数据删除流程，不过我们可以在今年看到这种功能的推出。最后，如果系统具有很高的数据冗余率的话，就可以缓解一部分性能上的难题，因为在随后奇偶的备份处理中越来越少的数据被写入。这里所说的越来越少的写入不仅仅指数据实际写入越来越少，而且还指需要计算的RAID校验位也越来越少。

如果你的基础架构每小时可以传输超过2TB的数据，而且你的备份窗口也需要每小时超过2TB的数据传输，那么post-processing系统的速度可能更适用于这种情况。这通常意味着你有大量数据组，更可能在系统环境中依赖于磁带设备。

首先确保整个磁盘备份解决方案——备份库到磁带数据的重复数据删除——针对日常备份策略可以维持一定的速度水平。重复数据删除并不是唯一的瓶颈。此外，如果你依赖于磁带的话，确保向磁带的集成操作是满足你的测试标准的。如果电子数据库也要求有一定容量的话，那么也将其纳入完整测试日常备份策略的测试标准中。

恢复性能

Post-processing解决方案也具有很好的恢复性能，因为将数据以原始状态保存对快速恢复来说非常重要。并非有所的post- processing的处理方式都完全相同。有些是尽可能地确保更多本地数据可用，有些则是保存备份流程的最新数据版本。不管怎样，对重复删除数据的恢复的确是存在一些性能问题，但是与备份相同，确保环境中没有其他可能引发更大问题的瓶颈。网络、服务器快速接收数据的能力、恢复流程中所有RAID校验数据的重写要求等等，都只说明了一个简单的事实，那就是写入要慢于读取。

如果速度是如此重要的话，那么就应该考虑选择其他像持续数据保护（CDP）这样以实际原始格式进行数据保存的解决方案。大多数这样的解决方案允许你从数据的备份副本启动进入系统，消除了从恢复流程中的数据传输。

灾难恢复

正如前面所说，post-processing一个最大优点就是可以在数据写入以及备份完成之后进行重复数据删除。post-processing 不那么依赖于处理能力，但是它却带来了一些在灾难恢复处理方面的挑战。Post-processing流程必须在备份数据复制完成之后进行，取决于系统架构和数据量，这就需要耗费很长的时间。虽然没有几家厂商报告他们post-processing的重复数据删除时间是多少，但是我们估计大约为每TB数据需要1到3个小时，数据量的不同时间也有很大差异。

这里一个重要的测量标准就是post-processing对灾难恢复复制窗口的影响。如果要求在一个设定窗口中将数据传输到离线站点中，那么你也许没有足够的时间来完成备份工作、运行重复数据删除流程、然后复制数据。如果离线保护很重要的话，那么缩减的复制时间就迫使用户具有很高的带宽。

即使没有一个需要进行灾难恢复的设置窗口，你自己也是希望能够在下一次备份完成之前更好地完成工作。如果你花了7个小时来备份10TB的数据，那么接下来就要化15个小时来分析和重复删除这些数据（假设重复数据删除过程每小时处理1.5TB数据），最后你只剩下2个小时来启动下一个备份窗口将所有数据复制到远程站点中。而且如果用户无法正常发送数据的话，你甚至没有时间对其进行纠错。

在inline处理过程中，数据进入应用的时候就启动了复制流程，这样即使备份窗口所需的时间翻倍，因为你开始复制较早，所有你的净备份处理速度实际上更快一些。虽然这也许不是你作出决策时考虑的唯一因素，但确实需要你认真考虑。

重复数据删除并非首要需求

重复数据删除并不是所有解决方案的重点。根据你的环境来说，现在容量问题可能更重要一些，还有能源管理存储、数据保留、紧密的磁带集成以及通过iSCSI从备份副本中启动等等。所有这些都可能是关键因素，如果你的数据中心存在这些因素，你就必须谨慎地考虑。

总结

当你在inline以及post-processing中作选择的时候，了解你需要怎样的备份性能、你能够提供怎样的备份性能、你需要在多短时间内创建备份数据的灾难恢复副本、以及是否有其他因素比重复数据删除更重要等等这样问题都是非常重要的。