Tivoli Storage Manager(简称TSM)是源自IBM的备份归档软件。用于目前主流数据应用的数据保护。本期活动主要针对TSM在日常工作中的各种场景和常用故障进行了探讨,非常感谢大家的踊跃参与,下面是会后我对活动的内容做的一些整理和总结。
Tivoli Storage Manager(简称TSM)是IBM推出的一款备份软件,能够为大型的企事业单位提供可靠的集中数据备份管理,是业界最主要的备份软件之一。Tsm支持以下类型的数据备份:
一般来讲,我们需要如果需要对某款应用进行保护,安装对应的模块即可。比如,需要对oracle数据进行保护。需要安装如下模块:
以TSM为例,TSM支持各种主流操作系统的备份,实现方式分别如下:
windows、linux、aix:cristie公司的cbmr或tbmr,支持操作系统的备份。和ibm有合作关系,好像可以买tsm的时候一起下单。可独立使用,可集成到tsm里,受tsm统一调度管理。同时支持win linuxaix。恢复的时候需要使用cbmr的引导光盘。独立收费,需要激活码。首推的,非常好用。除了这些,cbmr还支持hp-ux和solaris的系统备份。
aix:sysback,ibm自己的aix系统备份工具,优势是免费,集成度高。劣势是必须搭配nim使用。也就是说你环境里至少2台小机。配置复杂。
windows、linux:早期还有fastback,ibm自己的快速备份软件。支持win和lin操作系统的备份,属于独立的产品线。现在产品线已经停了。
首先,从VMware的备份来讲,VMware有两种备份实现方式
目前,TDP for Database支持MS sql server、db2、oracle等主流数据库。对于sql server和oracle来说,需要购买TSM FOR DATABASE模块,然后安装对应的模块来实现;对于DB2来说,安装TSM的ba client即可直接支持,不需要额外购买相应的模块。
对应各数据库来说,TSM的备份模块仅提供了备份通道,实际上还是通过数据库自身的备份工具来实现。以oracle为例,在安装配置好tdp for oracle后,备份还是使用rman,仅通过tdp的通道将数据备份到tsm所管理的磁带库中。
TSM作为一款功能强大的备份软件,底层有着自己清晰的逻辑架构。要想学好并灵活的应用tsm软件,需要对TSM底层的架构及相关概念有一个清晰的掌握。在TSM的架构中,主要分两大块:
1.策略层:含以下概念
2.存储层
物理存储设备和逻辑存储概念通过设备类关联起来,存储层和策略层通过副本组关联起来,下图:
回答:verexists:指定当前在客户机文件系统中的文件所保留的最大备份版本数,如果某个备份操作超过了限制,则服务器使磁带库中最旧的备份版本到期。(即代表文件系统中有的文件在磁带库中保留的版本数)
版本数既文件的个数,比如verexists=2 ,则有文件/backup/file1,第一次备份保留一个版本,第二次备份,又会重新备份一次,同一个文件总共2个版本,但可能文件内容不一样了(因为文件被修改了)。
如果verexists=1,则第二次备份时,就会将第一次备份的文件删除掉,保留第二次最新的版本。
最新的版本叫ACTIVE的版本,其他的版本都叫INACTIVE的版本。INACTIVE的版本可以通过 QUERY -INACTIVE参数查询出来。但一旦版本保留时间超过了retextra规定的保留天数,则TSM将把版本变为过期的(expire),用-inactive参数无法查看到。只能释放掉文件(expire inventory)。
verdeleted:指定要保留的文件备份版本的最大数目,该文件经TSM备份后,已从客户机文件系统中删除。
如果用户从客户机文件系统删除文件,则下一次备份导致服务器让超过此数值的文件的最旧的版本到期。保留版本的失效日期由RETEXTRA和RETONLY参数指定的保留时间决定。
此参数就是说如果主机上删除了这个文件,那么TSM中继续保留多少个版本数。如果verdeleted=0,则主机上删除了文件,则TSM也将文件删除掉。没有起到备份的意义。verdeleted=1代表如果主机上删除了文件,则TSM中仍然保留最后1个版本,但是是INACTIVE的了。verdeleted=2,是说如果主机删除了文件,则TSM中保留2个inactive的版本
retextra:当版本成为非活动版本以后,指定保留此备份版本的天数。当客户机存储更新的备份版本,或客户机删除工作站中的文件,然后运行完全增量备份时,文件的备份版本变为非活动。服务器根据保留时间删除非活动版本,即使非活动版本数超过VEREXISTS或VERDELETED参数容许的数目。缺省值是30天。
此参数就是说当主机上的文件被删除后,TSM中如果定义了还保留有版本,则此参数指定改版本保留的天数。
retonly:指定已从客户机文件系统中删除的文件的上一个备份版本要保留的天数,缺省是60天。
此参数就是说主机上文件被删除后,TSM中保留的最后一个版本的天数。
以上四个参数一定要记住。否则将酿成大错。
客户一般是把文件备份到TSM里面以后,就把文件从主机上删除掉了。看LOG什么的都正常备份了。
每天对同一个目录做备份,每天做删除,年复一年。
然后直到有一天,要恢复数据了,发现以前备份的数据都不在了,为什么?为什么?
因为:verexists=1 verdeleted=0
回答:通过上面的介绍,我们对TSM的策略层面和存储层面有了一个简单的理解。基于这个理解,在设计调度的时候可采取正反向两个方向去推论。
对于同一节点的数据保留数据的期限不同比如每天备份保留一个月每月备份保留1年每年备份保留10年这样的保留策略。TSM 要设置并指定不同的管理类不同的节点或者添加排除等而目前很多其他的备份软件只需要指定不同的保留策略就可以了。 TSM有没有这种简单的做法?
回答:TSM使用两种方法来解决:
回答:库在TSM里的物理对应就是机械手
池是个逻辑概念,可以由不同的介质类型构成,比如文件、lto等等。可以通过设备类指定。
存储池再和副本组中的dest参数关联。对应到不同的策略域
这样就形成闭环了
从A地将数据备份到B地,走TCPIP,每周的全备数据量比较大,一周时间内无法完成,带宽无法提升,还有别的什么方式吗?
回答:实现方式有两种:
1.基于TSM实现:比如直接使用客户端备份或使用node replication。那么需要在传输上下功夫。利用源端消重技术可以有效减少备份传输过程中的数据量。
2.基于设备实现:比如两端的存储设备本身具备远程复制属性,比如datadomain的虚拟带库。这样就完全靠硬件来实现了。
回答:不管是哪一款备份软件,对备份数据备份流程的控制尤其重要,特别是采用消重技术的备份,对备份数据的控制效用将直接影响消重性能。
消重技术以变长、定长两种为例,顾名思义变长是可以根据数据长度动态调整切片长度(如EMC DataDomain),定长仅仅是以固定长度对数据进行切片。
切片完成后,片(piece)的命中率直接决定消重性能。piece的命中率越高,消重越明显。因此如何控制备份片(backup piece)单一度且相似度成为重点。
我们知道Oracle的Rman脚本里,有一个fileperset参数来控制每一个backup piece里会包含多少个data file。设想一下,如果fileperset越高,那每个backup piece就会包含更多的data file,backup piece的杂糅度就会越高(data file会被混乱随机的组成一个backup piece,并不是每次都按照同一个顺序拟成),那么消重切片后piece的重复率必然低。
综合分析,一个合理的fileperset值将有效提升消重效率,fileperset越小越好,理论为1最好(如果没有多路复用的情况,一个流会话会占用一个备份设备)。
接下来关注备份通道数,Oracle的备份效率与数据结构类型、数据大小以及备份配置等息息相关。
如何合理规划备份通道数?关于此问题,我们需要了解一个概念——多路复用(multiplexing)。这个功能能够让多个oracle channel的备份流写入一个磁带机,如rman里分配了四个通道,但备份只有一个磁带机在跑。对于单个磁带机来讲,连续、大量的数据流具有更高的写入效率,如果单个backup piece数据量偏小就需要适当提高multiplexing的复用效率:允许x个会话同时写入该设备(此操作提高数据杂糅度会降低后端消重效率)。
对于Oracle而言,如果数据库性能允许,更多的channel会带来更高的数据读取效率,备份速度越快。然而考虑到备份对业务的影响以及并发性能的限制,最佳的通道数需要多次调整尝试。
除此之外若是oracle的消重备份,如果设置rman读取datafile时的读取块大小以及备份软件写数据的块大小以及设备消重的最小长度呈倍数关系,在消重效率和备份速率上都会有一定提升。
TSM for oracle的模块所起的作用,简单理解仅仅是提供了备份恢复的通道而已。所以在处理这个问题的时候先不要被tsm迷惑,仅从单纯的oracle rman角度去考虑即可。
实践上,rac环境的备份恢复仅在一个节点做就可以了,操作步骤基本上和单机环境没什么区别。
唯一需要考虑的一点就是rac环境下两边日志是存储在共享存储还是两边各是个的,要确保备份恢复的动作可以同时获取两个节点的归档信息,其他就没啥区别了。
有个关于TSM的LOG问题。一直也没搞清楚,
以前用TSM5.2 5.3.在不同的平台。不同的带库上都遇到过。q db或者Q LOG增长的异常,用不了多久就要去扩充TSM DB的容量。但是有的带库这个值就很低。几乎不怎么增长,有人有遇到这样的情况吗,这个DB库的增长是怎样的一种工作机制呢。有那些参数影响到它呢
回答:首先说下原理,tsm自身的db用来存放备份元数据及相关的策略等信息。db的大小和这些是相关的。我之前接触的一个案例,tsm v5,100多个节点,大量的碎文件,dbvolume配了好几个。因为用户需求,需要清掉所有的备份,删了好几天,一边删除一边可以明显的看到 q db在显著下降。
然后说下可能,个人理解一种可能是正常情况,由于业务需求导致的。另外一种可能就是bug了。需要仔细检查,并根据当前的版本信息,去查一下更新补丁的说明,看看已解决的问题里是否有相关项。
TSM自v6版本开始引入db2,与之前版本不同的时候,对tsm自身db要求要经常备份,否则归档日志会越来越多。这个是另外一种情况。建议条件满足的话可以考虑升级到新版本,db2对元数据的处理和大数据支持方面应该会有较大的进步。
如果一定要深入研究,可以通过tsm数据库中的三个基本表(SYSCAT.COLUMNS SYSCAT.ENUMTYPES syscat.tables)去观察相关的表信息。
回答:MHVTL 开源虚拟磁带库软件
官方网站:https://sites.google.com/site/linuxvtl2/(需墙)
部署环境:
DataDomain 4200 (OS :5.5)
HP小型机(HP UNIX 11.31)
现象描述:
1,在DataDomain的VTL里虚拟了16个drive,分享给HP小型机备份使用,。
2,在DataDomain上能够识别HP小型机的HBA卡WWNN,中间链路正常。
3,HP小型机上使用ioscan只能识别其中8个drive,能够正常查看drive信息、使用drive进行备份。
4,HP小型机上再次执行ioscan重新扫描设备,系统日志并无报错,ioscan正常完成。
4,将DataDomain VTL里虚拟的这16个drive共享给Linux主机,16个磁带机正常识别,并能正常备份。
排查思路:
1,HP小型机上识别的8个drive,能够正常查看drive信息、使用drive进行备份。
【部分磁带机正常】
2,在DataDomain上正常识别HP小型机的HBA卡WWNN,能够正常配对。
【中间链路无问题】
3,查看IOSCAN时系统日志,无报错。
【识别过程无报错】
4,将DataDomain VTL里虚拟的这16个drive共享给Linux主机,16个磁带机正常识别,并能正常备份。
【所有共享的drive状态正常】
5,定位问题根本在HPUNIX小型机上。
【OS上找问题】
6,查询HP UNIX设备管理器知识库以及DataDomain知识库。
【查询手册往往是最可靠的方法】
7,在HP UNIX知识库上“HP/UX addressing”一节里定位了VTL drive设备寻址问题。
【设备寻址问题】
8,在DataDomain上“VTL Drive Addressing in HP-UX”找到如下信息:
【一般关联性问题都会在厂商手册中标注】
HPUX only allows 8 LUNs per target with Data Domain system VTL.
VSA addressing is only necessary to see more than 8 LUNs. Also note that device special files will change unless you are using 11iV3 (aka 11.31) and persistent DSFs.
解决方法:
1,在DataDomain上将识别的HP小型机上的 initiator改成VSA( Volume Set Addressing)模式。
2,在HP小型机上设备配置里完全删除已识别到的8个drive配置信息。
3,重新执行ioscan扫描DataDomain VTL drive,正常识别16个drive。
故障现象:无法进行每天backup_db的操作;在重启TSM的时候发现,612ABF(ORAPOOL)试图进行reclamation的步骤,但是因为在ORAPOOL中没有其它磁带,所以一直报scratch volume not available的错,同时报reclamation failure和mount failure
故障分析: ORAPOOL中唯一的一盘磁带612ABF的空间已满,所以需要用一盘空白磁带(scratch volume)进行reclamation的操作。由于没有空白磁带在同一个storage pool中,所以造成612ABF无法mount,导致备份操作失败
故障解决方法:故障在加入一盘新的空白磁带SHA476后得到解决。以下是加入新磁带的详细过程和命令: (在操作时,开启另外一个AIX窗口,用dsmadmc–console命令打开一个可以监控TSM log的窗口) 1)label libvolume 3583lib sha476 checkin=scratch overwrite=yes 这时系统在TSM log窗口会给出一个request号,并要求把空白磁带放入3583带库的I/O station中;把磁带放入后,用这个命令继续操作: reply <request号>系统会自动完成把磁带加入libvolume的操作
tob_id_3541
以上命令把sha476加入到libvolume中去,状态设为scratch;可以用这个方法对这条命令的操作结果进行验证: query libvolume可以看到sha476已经被加入,且状态为scratch 2)define volume orapool sha476 这条命令把sha476加入到orapool中去完成以上2步操作之后,系统重新发起reclamation的操作,成功mount 612ABF和scratch volume sha476,完成reclamation操作
场景:如果我们的备份对象配置到了hacmp或者其他集群环境下,就意味着,如果资源发生切换,必须要确保备份的调度还能执行。
应对:
当时第一反应是将调度相关的命令配置到hacmp的起停脚本里。调度启动命令放到hacmp的启动脚本,调度关闭命令放到ha的停止脚本里。实施后发现一些问题,有时因为意外原有调度进程死掉了,没有想过的监测机制启动,导致调度窗口丢失。或者发生切换后,原节点的调度进程没正常退出,导致调度接收混乱。
后来想了想设计了一个脚本,放到crontab里,定期执行一下。脚本内容如下:
#!/bin/bash
#description: TSM db2 sched
db2=$(ps -ef|grep "db2sys" |grep -v grep)
tsmsched=$(ps -ef|grep "dsmcsched" |grep -v grep)
if [ "$db2" == "" ]&&[ "$tsmsched" == "" ];
then exit 0
elif [ "$db2" == "" ]&&[ "$tsmsched" != "" ];
then kill -9 `ps -ef |grep "dsmcsched"|grep "tsmdb2"|awk '{print $2}'`
elif [ "$db2" != "" ]&&[ "$tsmsched" == "" ];
then nohup /usr/bin/dsmcsched -se=tsmdb2 >/dev/null 2>&1 &
elif [ "$db2" != "" ]&&[ "$tsmsched" != "" ];
then exit 0
fi
脚本以db2 with hacmp为例,以db2sys进程为判断对象,如果监测到db2sys进程启动,调度不存在则启动。如果db2sys进程不在,调度进程在则杀掉,调度进程不在自动退出。
后续运行良好,中间意外切换了几次调度都没丢正常备份。
虽然是野路子,胜在好用,分享给大家!
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞8
添加新评论2 条评论
2021-11-29 16:54
2017-01-23 23:16