重复数据删除的时机问题

核心提示：时机问题现在重复数据删除领域最热门的话题之一就是应该在什么时候启动重复数据删除流程？应该选择在数据传送的过程中进行处理的in-line方式还是选择在完成备份之后进行处理的post-process呢？在上一篇文章中我们已经谈到了关于重复数据删除更为详尽的解释，这里我们快速回顾一下，重复数据删除的时机问题，重复数据删除是一

时机问题

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

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

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

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

状态问题

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

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