有TSM专业人士吗，请教progressive incremental backup

hahawa_sapi

小弟刚自学IBM TSM不久，到了progressive incremental backup这里，俺愚钝，怎么也不能领悟，望专家指教。

就我的知识，backup software大都采用full+incremental或full+diff的方式，full+diff跟TSM这个没有相似点暂不提。就说这种Full+incremental的方式，假设7天为周期天，Monday Full backup, Tue-Sun incremental only。原始数据10GB，Tue－Wed各写入1GB，Thur无变化，Friday写入2GB，Sat-Sun无变化。我的理解是，备份软件在Tue, Wed各备份新写入的数据1G，然后周五备份2G。如果Sat出现disaster需要recovery, 备份软件恢复到最近的点即周5备份后，应该需要refer各个incremental+full，即 2G+1G+1G+10G

以上就是一般的backup,drawback是过程很缓慢，现在说TSM，IBM的手册上说它的progressive incremental客服了这个问题，原话如下：   
TSM takes incremental backup one step further. After the initial full backup of a client, no additional full backups are necessary because the server, using its database, keeps track of whether files need to be backed up. Only files that change are backed up, and then entire files are backed up, so that the server does not need to reference base versions of the files.
我无法参透的就在这，根据IBM手册的描述，TSM也是用数据库track变化的数据，然后只备份change过的，这本来就是incremental的原理啊，那么TSM和我上面说的那种incremental方式区别到底在哪里呢？就上面的例子，TSM只备份变化的，那同样也是Tue,Wed各1G，Fri 2G, 周6 DR的时候，为啥它就可以"no need to reference base version"了呢？

[ 本帖最后由 hahawa_sapi 于 2011-9-24 16:42 编辑 ]

neal

我搞另一款backup software, 但原理应该是差不多的。
楼主的理解是对的。但是我觉得你对手册的理解不准确。
After the initial full backup of a client, no additional full backups are necessary
这个是说你只要第一次Monday 做一个full backup 就行了，不必每个Monday 都做full backup.

hahawa_sapi

原帖由 neal 于 2011-9-24 12:27 发表
我搞另一款backup software, 但原理应该是差不多的。
楼主的理解是对的。但是我觉得你对手册的理解不准确。
After the initial full backup of a client, no additional full backups are necessary
这个是说你只 ...

对TSM就是只需要1次full, 然后一直incremental就可以了，这也是TSM和netback, backupexe等不同的地方。关键是为什么可以这样？DR restore的时候，为啥不需要incremental+full就可以。

kukumalu

你不要把DR考虑进去，那个DRP是TSM专门的一个compoenent，容易说混。DR的概念比TSM大的多，再说现在因为SLA的要求，加上SAN价格的降低，TSM在DR里的角色越来越弱了。

比如说你有九个文件，1，2，3，4，5，6，7，8，9，第一次的备份是全备份，TSM和传统意义上的备份没有区别；

第二天你改了文件2，增量备份文件2，TSM和传统意义上的备份没有区别；

第三天你又改了文件2，增量备份文件2，TSM和传统意义上的备份区别出现了。
按照传统的增量备份，恢复起来文件1是第一天的全备份＋第二天的变化＋第三天的变化。这个时候如果你丢了第二天的变化的备份，那么第三天的备份也就没有意义了。但其实这种所谓的传统增量备份现在只存在于教科书上了，十几年前我们用dds磁带做增量备份就是这样。
但TSM是用数据库来管理备份版本的，IBM收购TSM这么多年终于用DB2重写了TSM后台的数据库，现在好用很多了。你恢复的时候呢，只需要告诉TSM restore到哪一个point of time，TSM自己去后台处理什么base，变化版本的问题，不会跟古时候一样先写base，然后插第二天的tape，restore第二天的变化，然后插第三天的tape，resotre第三天的变化。

其实呢，这个东西更多的是写给古时候的人忆苦思甜的市场版语言，你没必要在这个上面太纠结了，知道个意思就好了，置于她后台到底是怎么处理实现的，去琢磨这个不如把剩下的那几百页redbook看完。

hahawa_sapi

谢谢指教。那为什么说只有TSM才能做仅1次full backup呢？我朋友做netbackup,作为另外一款很流行的enterprise level软件，netbackup仍然需要在一定周期全备。全备的意义很大程度就在于抵消incremental的restore drawback。

我其实就想知道，TSM怎么能够在不refer到full backup的情况下，做数据restore? 当然我是指系统恢复。如果单说某1个文件，那么任何backup software都可以做到只恢复那1个指定的文件，TSM的优势到底在哪里？

neal

原帖由 hahawa_sapi 于 2011-9-24 19:59 发表
谢谢指教。那为什么说只有TSM才能做仅1次full backup呢？我朋友做netbackup,作为另外一款很流行的enterprise level软件，netbackup仍然需要在一定周期全备。全备的意义很大程度就在于抵消incremental的restore drawback ...

应该是系统自动做 consolidation. 当做 incr backup 时，自动link到full backup. 做了一个backup chain. 但是，如果要DR restore, 当然需要refer 到 full backup。你给出的手册部分没说做DR restore 时不需要 full backup.

飞飞鱼

全都混在一起了，继续看书吧。

TSM的优势在于他是IBM的备份软件，是IBM推的各种存储解决方案里的部件。真的技术上有多突破，我们的水平还到不了做评价的程度。

backup <--> restore
archive <--> retrieve

如果你说的全备是backup，TSM确实在应用面上看只用做一次，你只有一个node definition，除非给多个node definition。但为什么要做多次呢？至于其他产品，不care。

如果你说的全备是archive，你想做多少次做多少次。Archive毫无疑问的Retrieve起来比Restore Backup要快的多，但也占磁带就是了。

至于一定周期全背，要看目的和意义是什么。比如说金融公司的数据是要求保存多少年的，当然要做Archive全备。如果只是Incremental backup，保存的版本是有限制的，不可能把所有的变化都保留下来，mgtclass控制这个的。你自己做个试验，找一个系统变化很频繁的文件，看看dsmc q backup和dsmc q backup -ina的区别就明白了。

木子

TSM restore的时候很慢是不是是因为要过所有的incremental backup。time vs space

飞飞鱼

快，慢都是相对的。

“慢”有很多原因：
可能是client机器本身就慢；
也可能是网络拥挤，
也可能是TSM Server CPU/Mem/Paging Space处理不过来；
也可能是你的任务优先级太低，被别的任务占去了Tape Driver；
也可能是你的备份被优化分散到了不同的tape上，带库要不停的mount / umount不同的tape；
也可能是你备份的是大量小文件，我碰到过一个极端的例子，几百G的一个小文件系统，TSM scan了4，5个小时才开始备;
当然也可能是RP问题hehe

hahawa_sapi

原帖由 neal 于 2011-9-24 23:23 发表


应该是系统自动做 consolidation. 当做 incr backup 时，自动link到full backup. 做了一个backup chain. 但是，如果要DR restore, 当然需要refer 到 full backup。你给出的手册部分没说做DR restore 时不需要 full backup.

那么TSM所宣传的progressive incremental的优势到底在哪里呢? 如果说恢复单个file, netbackup甚至backupexec,networker,一样做到。我们公司的TSM backup一年都不做一次full backup的，那么如果有DR，岂不是要N天来恢复？我觉得TSm肯定有方法解决这个问题，IBM说它并有incremental backup和differential restore的优势，可以不用像netbackup那样比较传统的方式去恢复系统，但是我就是不清楚它怎么做到的。

[ 本帖最后由 hahawa_sapi 于 2011-9-25 20:35 编辑 ]

JuJu

本来就没有多少特别的优势, 表把progressive incremental backup看得多么希奇, 这个feature Netbackup 和 CommVault Galaxy 都同样有, 叫做synthetic-full backups, 基本上一回事. 要restore 全部的话还是需要最初的的那个full backup的.

hahawa_sapi

原帖由 JuJu 于 2011-9-25 22:21 发表
本来就没有多少特别的优势, 表把progressive incremental backup看得多么希奇, 这个feature Netbackup 和 CommVault Galaxy 都同样有, 叫做synthetic-full backups, 基本上一回事. 要restore 全部的话还是需要最初的的那个full backup的.

这样啊。。我还以为TSM比较稀奇。。。因为放狗搜了一下说TSM的backup, restore又快，又节约network bandwidth云云，我就在想它和其他的产品到底backup, restore方面有啥不同。

hahawa_sapi

各位，还举个类似的例子，假设我有txt文件example.txt, Monday做full backup的时候，里面的内容是a1,a10 Tue写入a2, example.txt=a1,a10,a2. Wed 改变a1为a3, example.txt=a3,a10,a2. Tue不变，Fri改a2为a5, example=a3,a10,a5，Sat, Sun不变。

假设我下周1的早上要恢复到Fri晚的最后一次备份example.txt，如果说只是incremental backup, 那么其实Tue, Wed, Fri 应该只记录了所改变的内容即a2, a3, a5, 请问此种情况下TSM是怎么操作的来得到 example.txt=a3,a10,a5？

[ 本帖最后由 hahawa_sapi 于 2011-9-26 21:10 编辑 ]

12oz

原帖由 hahawa_sapi 于 2011-9-26 21:04 发表
各位，还举个类似的例子，假设我有txt文件example.txt, Monday做full backup的时候，里面的内容是a1,a10 Tue写入a2, example.txt=a1,a10,a2. Wed 改变a1为a3, example.txt=a3,a10,a2. Tue不变，Fri改a2为a5, example=a3,a10, ...

你想太多了。 backup软件不会管文件里面具体的内容，只是发现了文件有改变就直接备份整个文件。增量备份是对整个backup set来说的，单个文件只有不备份和全备份。

hahawa_sapi

原帖由 12oz 于 2011-9-26 21:15 发表
你想太多了。 backup软件不会管文件里面具体的内容，只是发现了文件有改变就直接备份整个文件。增量备份是对整个backup set来说的，单个文件只有不备份和全备份。

明了。。多谢！ 稍微改一下问题

现在假设example是一个目录,Monday做full backup的时候，里面有文件a1.txt,a10.txt, Tue写入a2.txt, example里有a1,a10,a2.txt； Wed改变a1为a3, example里有=a3,a10,a2.txt; Tur不变，Fri改a2为a5, example里有a3,a10,a5.txt，Sat, Sun不变。

假设我下周1的早上要恢复目录/xx/example到Fri晚的最后一次备份，因为是incremental backup, 那么Tue, Wed, Fri应该只备份了所改变的内容即a2.txt, a3.txt, a5.txt, 请问此种情况下TSM是怎么操作的来得到 example目录下到周5晚的内容即a3,a10,a5.txt？

kukumalu

受不了了，为什么不看真正的TSM管理，哪怕应用内容呢，老是纠缠这些。

回头望

LZ问的问题在备份管理中几乎无人关注的，备份软件有数据库记录了哪一个时间的备份在什么地方，需要的时候去找就可以了。

hahawa_sapi

回16F, 17F两位TX，

我没有只是纠缠于这个，我一直在看其他内容，只不过比较好奇这个progressive incremental内部的原理。这也不会阻碍我看其他的吧。

JuJu

原帖由 hahawa_sapi 于 2011-9-27 19:04 发表

明了。。多谢！ 稍微改一下问题

现在假设example是一个目录,Monday做full backup的时候，里面有文件a1.txt,a10.txt, Tue写入a2.txt, example里有a1,a10,a2.txt； Wed改变a1为a3, example里有=a3,a10,a2.txt; Tur不变，Fri改a2为a5, example里有a3,a10,a5.txt，Sat, Sun不变。

假设我下周1的早上要恢复目录/xx/example到Fri晚的最后一次备份，因为是incremental backup, 那么Tue, Wed, Fri应该只备份了所改变的内容即a2.txt, a3.txt, a5.txt, 请问此种情况下TSM是怎么操作的来得到 example目录下到周5晚的内容即a3,a10,a5.txt？

你再仔细看看文档资料, TSM 把最近一次backup 里的文件作为active, 原来老的版本作为inactive, 因此,
Monday full backup后, example 目录下有a1.txt,a10.txt, 为 active;
Tue写入a2.txt, a2.txt 为active, a1.txt,a10.txt 无改变, 仍为 active;
Wed改变a1为a3, a1.txt 现在为inactive, a3.txt 为active, a10.txt 无改变, 仍为active;
Tur不变，Fri改a2为a5, a2.txt 现在为inactive, a5.txt 为active, 而a3.txt, a10.txt 无变化, 仍为active;
Sat, Sun不变;

下周1的早上你要恢复目录/xx/example到Fri晚的最后一次备份, a3.txt 会从Wed 的backup里得到, a5.txt会从 Fri 的backup里得到, a10.txt 会从Monday fullback 里得到.

Fernando

前两周EMC来介绍Data Domain，号称可以根据现有备份来压缩磁盘。比如周一的full backup 100G, 周二的full backup １０１G，两个logical full backup实际占用空间会是１０x G

rayki

deduplicate..没啥特别的。   tsm只有少数银行的大机在用了。。连ibm自己的大机team都走得差不多了。。 为什么不看看netbackup的东西？

12oz

原帖由 Fernando 于 2011-9-28 10:41 发表
前两周EMC来介绍Data Domain，号称可以根据现有备份来压缩磁盘。比如周一的full backup 100G, 周二的full backup １０１G，两个logical full backup实际占用空间会是１０x G

It is called deduplication?

neal

原帖由 Fernando 于 2011-9-28 10:41 发表
前两周EMC来介绍Data Domain，号称可以根据现有备份来压缩磁盘。比如周一的full backup 100G, 周二的full backup １０１G，两个logical full backup实际占用空间会是１０x G

这也吹得太神了。 即使能实现，也是一种天时地利人和的极端情况。通常情况下，是不可能达到的。
100G的数据量，dedup 50%就不错了。

JuJu

原帖由 Fernando 于 2011-9-28 10:41 发表
前两周EMC来介绍Data Domain，号称可以根据现有备份来压缩磁盘。比如周一的full backup 100G, 周二的full backup １０１G，两个logical full backup实际占用空间会是１０x G

Data Domain 用在TSM 环境不错的, TSM 大客户们最大的挑战是随着环境的越来越大, backup window 越来越不够, progressive incremental backup的性质决定了TSM 必须要很多时间来做这些maintanenance tasks, 24hr duty cycle最终就不够用了, 用 Data Domain 来代替tape library, 不单单是省磁盘空间的问题, 主要是可以省很多做 maintanenance tasks 的时间, 24hr duty cycle才可以继续work, 用Data Domain replication, 把offsite copy 也解决了, 赫赫.

规模小点的公司就不会有这个问题了, 24hr duty cycle 不存在时间不够的问题, 也没必要一定要引进Data Domain 了, 不便宜.

Fernando

不懂TSM，看上去是先天缺陷啊

JuJu

也不算是先天缺陷, 别的backup 软件也有随着数据增长backup window越来越不够的问题, database 都越长越大了, 以前几个TB的database 就很惊人了, 现在几十个TB的都有, full backup 甚至有可以费时一个星期以上的.

hahawa_sapi

原帖由 JuJu 于 2011-9-27 22:27 发表


你再仔细看看文档资料, TSM 把最近一次backup 里的文件作为active, 原来老的版本作为inactive, 因此,
Monday full backup后, example 目录下有a1.txt,a10.txt, 为 active;
Tue写入a2.txt, a2.txt 为active, a1.tx ...

很清楚，多谢！可惜我不能加分。

hahawa_sapi

原帖由 rayki 于 2011-9-28 10:50 发表
deduplicate..没啥特别的。   tsm只有少数银行的大机在用了。。连ibm自己的大机team都走得差不多了。。 为什么不看看netbackup的东西？

因为公司是用的TSM做备份，我觉得书在怎么看只能懂个概念，理解是怎么运作的，还是要实际操作才能真正熟悉。没办法，netbackup目前没这个条件。

Fernando

DB大了就不能那样总是做full backup了，如果对restore有要求，一定要自己的backup solution了

我发现很多公司和政府，没有data archive policy。几十年的数据放在一个DB里面也算了，至少移到另一个archive表去吧，再不行，表分个区也行啊，看到好多都在同一个表里，无语啊

12oz

原帖由 JuJu 于 2011-9-28 20:25 发表
也不算是先天缺陷, 别的backup 软件也有随着数据增长backup window越来越不够的问题, database 都越长越大了, 以前几个TB的database 就很惊人了, 现在几十个TB的都有, full backup 甚至有可以费时一个星期以上的.

这么多数据能不能分区备份(Oracle)？不会全部堆一起吧？