【IT168 资讯】

时机问题

    现在重复数据删除领域最热门的话题之一就是应该在什么时候启动重复数据删除流程？应该选择在数据传送的过程中进行处理的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系统的速度可能更适用于这种情况。这通常意味着你有大量数据组，更可能在系统环境中依赖于磁带设备。

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