重复数据删除的时机问题
2009-10-19 00:00:00 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閹冣挃闁硅櫕鎹囬垾鏃堝礃椤忎礁浜鹃柨婵嗙凹缁ㄧ粯銇勯幒瀣仾闁靛洤瀚伴獮鍥敍濮f寧鎹囬弻鐔哥瑹閸喖顬堝銈庡亝缁挸鐣烽崡鐐嶆棃鍩€椤掑嫮宓佸┑鐘插绾句粙鏌涚仦鎹愬闁逞屽墰閹虫捇锝炲┑瀣╅柍杞拌兌閻ゅ懐绱撴担鍓插剱妞ゆ垶鐟╁畷銉р偓锝庡枟閻撴洘銇勯幇闈涗簼缂佽埖姘ㄧ槐鎾诲礃閳哄倻顦板┑顔硷工椤嘲鐣烽幒鎴旀瀻闁规惌鍘借ⅵ濠电姷鏁告慨顓㈠磻閹剧粯鈷戞い鎺嗗亾缂佸鏁婚獮鍡涙倷閸濆嫮顔愬┑鐑囩秵閸撴瑦淇婇懖鈺冪<闁归偊鍙庡▓婊堟煛鐏炵硶鍋撻幇浣告倯闁硅偐琛ラ埀顒冨皺閺佹牕鈹戦悙鏉戠仸闁圭ǹ鎽滅划鏃堟偨缁嬭锕傛煕閺囥劌鐏犻柛鎰ㄥ亾婵$偑鍊栭崝锕€顭块埀顒佺箾瀹€濠侀偗婵﹨娅g槐鎺懳熺拠鑼舵暱闂備胶枪濞寸兘寮拠宸殨濠电姵纰嶉弲鎻掝熆鐠虹尨宸ョ€规挸妫濆铏圭磼濡搫顫嶇紓浣风劍閹稿啿鐣烽幋锕€绠婚悹鍥у级瀹撳秴顪冮妶鍡樺鞍缂佸鍨剁粋宥夋倷椤掍礁寮垮┑鈽嗗灣閸樠勭妤e啯鍊垫慨妯煎亾鐎氾拷

首先确保整个磁盘备份解决方案——备份库到磁带数据的重复数据删除——针对日常备份策略可以维持一定的速度水平。重复数据删除并不是唯一的瓶颈。此外,如果你依赖于磁带的话,确保向磁带的集成操作是满足你的测试标准的。如果电子数据库也要求有一定容量的话,那么也将其纳入完整测试日常备份策略的测试标准中。
恢复性能
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中作选择的时候,了解你需要怎样的备份性能、你能够提供怎样的备份性能、你需要在多短时间内创建备份数据的灾难恢复副本、以及是否有其他因素比重复数据删除更重要等等这样问题都是非常重要的。
更多精彩
赞助商链接