第二页
如果它允许你满足备份窗口的话，就无法支持多个这样的系统。这一点很重要，因为到目前为止没有哪个系统可以在独立的应用之间支持重复数据删除流程，不过我们可以在今年看到这种功能的推出。最后，如果系统具有很高的数据冗余率的话，就可以缓解一部分性能上的难题，因为在随后奇偶的备份处理中越来越少的数据被写入。这里所说的越来越少的写入不仅仅指数据实际写入越来越少，而且还指需要计算的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中作选择的时候，了解你需要怎样的备份性能、你能够提供怎样的备份性能、你需要在多短时间内创建备份数据的灾难恢复副本、以及是否有其他因素比重复数据删除更重要等等这样问题都是非常重要的。
网友评论