有关重复数据删除技术的五大误区（四）
关于实现方式的五大误区
“联机处理方式一定会降低备份的处理速度”
大量的实际备份案例证明，采用联机重复数据删除模式的备份设备，其备份速度比那些磁带备份以及普通的磁盘备份方式要快很多。大多数情况下，都可以达到40-50MB/s的备份速度，而在普通的备份环境中很难在单一备份数据流中实现这一指标。
“降低备份数据流的读入速度会造成严重的后果”
采用的重复数据删除技术是否会造成备份速度降低？是否比以往采用的磁带备份方式更快？备份过程是否能够满足备份窗口以及RTO的需求？实际上后者才是需要关注的重点。
另外，需要强调的是只有当重复数据删除处理结束，整个备份任务才能算真正完成。特别是，当你的后期处理重复数据删除设备的性能较差时，显然那会降低你的重复数据删除比。
“后期处理重复数据删除方式是当所有数据备份过程结束后开始的”
这是关于后期重复数据删除技术流传最广泛的观点，人们往往是从该处理方式的名称简单推断而来的。这也是为什么我倾向于采用异步处理方式来称呼该处理技术的原因。
后期处理方式一般是在虚拟的磁带介质写入备份数据后才开始处理过程的，换句话说就是等待虚拟磁带写满后或者备份任务结束后才开始。根据备份管理员对备份系统的不同设置，这一等待延迟从几分钟到数小时不等。
该等待时间从第一组备份任务传送备份数据流开始算起，当第一盘虚拟的备份磁带写满或第一组备份数据流写入结束后，此后的重复数据删除处理就不存在延迟等待问题。因为，当系统在进行前一写入备份数据的重复数据删除处理时，备份系统可以继续往后续的虚拟磁带介质中写入第二组或第N组的备份数据，从此刻起，这两部分的工作是并行进行的。
“后期处理重复数据删除方式会降低整体备份进程的速度”
如果能对备份设备进行合适的配置，这不应该是个问题。如果在现有的备份环境中出现上述情况，我们可以通过将重复数据删除处理分配到多个单独的服务器上来分担处理的负荷，虽然在对已写入的备份数据进行重复数据删除时，不同的处理引擎（重复数据删除处理服务器）会访问同一磁盘阵列，但是它们可以访问同一磁盘阵列的不同区域，完全可以实现高速并发处理，而不会和持续写入的备份数据流产生任何的冲突。所以，这种担心是完全可以避免的。
“后期处理重复数据删除的过程是在所有备份数据都已被复制到另外一个磁盘设备上后才会开始执行”
就像大多数夸大之词一样，这也是目前市场上最流行的误区之一。
当虚拟磁带介质被加载到驱动器时，虚拟带库会停止对其的重复数据删除处理，另外，当备份数据流正在写入虚拟磁带时，也会暂停重复数据删除处理。前者是因为虚拟带库认为此时可能正在进行数据恢复或复制操作，而重复数据删除过程不能与此类作用于同一磁盘阵列的读操作相互竞争资源。后者则是通过大量测试证明没有任何技术问题。
其实，在实际环境中，这根本不会成为技术问题，因为我们一般会将备份数据流写入多盘磁带介质，实际写入磁带的数量远大于我们实际拥有的磁带驱动器数。只要满足这个唯一的条件，那么当其他磁带正在进行复制或其他读写操作时，总有剩余的磁带介质可以进行重复数据删除处理。
而且，重复数据删除机制也支持此类智能化操作。 （目前仅有的担心是当备份软件正准备从某磁带介质读取数据时，虚拟磁带库系统会暂停重复数据删除处理，但请注意，并不是暂停所有磁带介质上的重复数据删除处理。 这个技术问题很快也会得到解决，至少有一家厂商声称可以通过分割磁带数据区域的方法来实现并发读写，即当备份软件正在对某盘磁带介质进行写入操作时，我们可以对该介质的其他部分进行重复数据删除处理，而不存在相互干扰的问题。）
当我们对重复数据删除的实现方式有所了解后，发现这不是一个简单的非此即彼的选择，当你采购具备重复数据删除功能的备份设备时，建议你的购买决定应该更多地基于设备性能、备份容量、性价比、服务支持以及厂商的专业背景等方面，而不是看其具体采用何种重复数据删除模式。
etsme是采用云计算原生技术打造的个人私有云/小型私有云产品，即刻入手etsme，探索更多贴心功能，掌控自己的数字世界。