本文作者Howard Marks是Networks Are Our Lives公司的首席科学家。这家公司总部位于新泽西州霍博肯,从事顾问工作。1987年以来,他一直专注于系统的分析和写作。 

DOSTOR存储在线4月11日国际报道：主存储应用程序，即使是简单的应用程序，比如托管用户的主目录，对延迟性也非常敏感。此外，主存储应用环境不是像备份应用程序那样将数据写入到少数大型文件，而是有数百万个各种大小的文件。由于每个文件都从一个新的数据块开始，因此数据插入或其他有可能带来块重整的修改只影响一个文件的数据。每个新文件都会重新调整流程。

基于软件的重复数据删除软件--尤其是那些在源服务器端进行重复数据删除操作的应用程序，比如Avamar、PureDisk或Asigra的Cloud Backup--也会使用文件开头和结尾来判断它们的块边界。这些应用程序首先判断哪些文件已经发生修改，比如传统的增量型备份，然后开始在每个文件上进行分块操作。

如果备份目标端的重复数据删除引擎知道磁带的格式或将Tarball这样的文件（也就是你的备份应用程序写入数据的文件）整合在一起，那么使用文件边界可以优化备份目标端的固定块分块流程。重复数据删除引擎可以在Tarball内判断每个文件的开头和结尾，并根据这些边界对数据块进行重新调整。内容感知功能同时也可以让备份设备看到索引标志，并为备份应用程序插入到Tarball的数据编写目录以防止它们遭到分块。

不过，固定块系统可能在某些数据上会水土不服。我知道一位Data Domain用户使用Exchange备份来测试赛门铁克的PureDisk重复数据删除。他们当时在Data Domain上根据给定容量的存储保存40个Exchange服务器备份，但是他们无法在同样的存储容量下保存4个被PureDisk执行重复数据删除的Exchange备份数据。Exchange数据是由小量大型数据库文件组成的，而这些文件会在备份之间发生内部改变。对于PureDisk的重复数据删除引擎来说，这是最糟糕的情况。现在，如果你使用固定块重复数据删除引擎，而数据块的大小比数据库页面还小，那么情况也很糟糕。

本文接：专家博客：重复数据删除的分块流程（上）