tsm文件级永久增量备份感觉不太合理

sylb

tsm文件级永久增量备份感觉不太合理,如果我第一次做全备的磁带坏了。那不就根本恢复不回去了吗? 是否得每周做个全备份啊.怎么设置.谢谢

wolfgroup

如果有这种忧虑，建议对primary storage pool设置copy storage pool。\r\n\r\n对于文件有数十TB需要备份，非TSM软件的周期性全备或者周期性合成全备是很痛苦的。\r\n\r\n如果一定要执行全备，可以使用dsmc selective

无牙

tsm应该会在后台做合成的。只要你的策略设置合理，这个问题是能避免的。

donggua0713

照LZ这样想,所有的增量备份技术都不合理,因为都存在全备的磁带坏了的情况啊~!

无牙

啊是这样，如果不合成，的确比较危险。

donggua0713

TSM 最大的特点就是恢复速度快,而且TSM中有如下技术来保证恢复速度:\r\n1.并置\r\n    这个技术具体是这样的,比如一台server,负责备份N台client,这N台client每天一起备份,那么,如果是在backup exec这样的软件里头,这N台client的备份数据是一起写到一盘磁带里面的(也可能是同一个卷池里面),这样,次数多了,一盘磁带写完了,又一盘,如此反复.会出现这样一个问题,当需要恢复这N台其中一台的数据的时候,这些需要恢复的数据有可能分布在同一个卷池的N盘磁带里面,那么,恢复的时候,就需要执行最少N次挂载磁带的操作,同时,磁带是顺序读设备,很有可能要从一盘磁带的头读到尾,才能找到需要恢复的那点数据,那么,挂载N次,加读N次磁带,需要的时间就会很多.无形中,浪费了时间.\r\n    在TSM中,有一个称为\"并置\"的功能,基本解决这种情况,并置.并置是指:在备份时,尽可能的把一个或一组client的备份数据连续的放到一盘磁带上.即,我有ABC三个client,同时备份,A备份到A号磁带,B备到B号磁带,C备到C号磁带,互相之间,不会串门.那么,天长日久,即使A备份使用了3盘磁带,恢复时,也只需要挂载3次磁带,并且顺序读磁带上的内容,这些内容都是属于它自己的,那么,恢复速度就比不使用\"并置\"要快.\r\n2.回收\r\n    另一种情况,还是关于N多盘磁带恢复的.假设,A号client备份使用了100盘磁带,但是由于文件保留策略,使得每盘磁带中只有一点点数据是有用的,其他的都过期了.那么,恢复的时候,需要挂载100次磁带,依次读出其中的那么一点点数据来恢复,那么,这显然是个灾难.\r\n    这种情况,TSM采用回收来解决.当100盘磁带,由于策略的原因,绝大部分文件都已经过期了,只有一点点数据有用,那么,TSM会读出这100盘磁带中有用的数据,写入到一个回收存储池,那么,这100盘磁带就无用了,可以把里面的数据删除,重新分配给其他的client使用,回收池中保持的这些有用的数据,又重新写入到相对较少的磁带里面,比如写到10盘磁带里面,那么恢复的时候,只要挂载10次,并且里面的数据都是有用的.不会造成上面的灾难.\r\n\r\n结合回收和并置,TSM可以提供比其他备份软件快的恢复速度.\r\n\r\n此外,TSM还有在DISK类存储设备上保持cache,时间点恢复,卷映像恢复等等方法提高恢复速度及效率.并可以采用备份集来进行不依赖TSM server的数据恢复.\r\n\r\n由于采用了并置及回收这些方法,TSM可以说是牺牲了备份的速度,来换取恢复的速度,这是在TSM的手册里说过N多次的,我记忆深刻.\r\n\r\n相对于磁带的安全,TSM和netbackup等一样,提供了copy池等等方法,即把文件备份到磁带里面,并把它COPY若干份,防止其中某一份坏了等等.\n\n[ 本帖最后由 donggua0713 于 2009-6-23 20:47 编辑 ]

donggua0713

TSM 更倾向于减少恢复时间,提高恢复效率,而不是减少备份时间.备份时,TSM一般先把数据备份到高速随机读写设备上(比如硬盘),然后使用后台管理任务,在系统负载较低的时候,把数据移动到磁带存储设备上,所以,备份的时候,N个client都是一起写到硬盘上的,并不挂载任何一个磁带.到备份完成后,系统空闲的时候,再把数据转移到磁带上,并在转移的时候,自动分辨数据所属的client,自动并置.所以,并不存在\"此外，在一些特别情况下，这种并置的工作方式还会导致备份时间窗口的增加，例如只有1台磁带机，n个client要写数据，就需要一个一个顺序执行备份任务，不能很好的利用磁带机的速度优势。\"这种情况.

wolfgroup

tsm没有直接“用并行流技术多个client同时写入一盘磁带”的功能，tsm解决这一问题的方法是先并发备份到Disk Devclass Pool,然后再迁移到Tape Pool.(Disk Devclass Pool是为并发写优化的)；如果磁盘空间无法容纳一次增量的内容，只能依此排队使用磁带机。\r\n\r\ntsm的collocation的确会带来备份mount磁带次数多的问题，但是付出这个代价的回报是，在恢复数据时mount磁带的次数少。 另外，collocation的level可配置的,可以是filespace,node,node group。 \r\n\r\ntsm的reclamation是日常的，是自动触发的，默认是一盘磁带有60%的reclaimable空间时，就会触发relcamation;而且relcamation使用磁带机的优先级比备份高。\n\n[ 本帖最后由 wolfgroup 于 2009-6-24 10:30 编辑 ]

wolfgroup

tsm是有版本的，是你所说情况的第2种。

donggua0713

对于TSM的自动回收,我有点不同看法,即:回收不能让TSM自己进行,因为回收优先级很高,并且占用driver,有可能导致其他的任务一直等待资源,无法完成,所以我一直都是手动回收的.