nkj827
作者nkj8272017-10-21 11:36
项目经理, 长春长信华天

TSM、NBU、Legato等备份系统运维难点与故障处理总结

字数 15743阅读 11522评论 4赞 13

TSM、NBU、Legato等备份系统运维难点与故障处理总结

随着企业信息化的建设,数据已经成为企业最重要的无形资产,为了保证数据的安全性和业务的连续性,企业都非常重视数据的备份工作。

现在主流的数据备份软件包括IBM TSM、Symantec NetBackup、EMC Legato等,IBM Tivoli Storage Manager简称TSM,TSM能够为用户提供企业级存储数据管理的全面解决方案,包括集中的数据备份与恢复管理、专业的数据归档管理功能、高级的分级存储功能和流程化的灾难恢复管理。Symantec NetBackup在备份过程中,客户通过网络将数据传送至NetBackup服务器,该服务器则通过使用相关策略为其选择最合适的存储介质类型。在恢复过程中,管理员能够浏览到用户需要恢复的数据和目录,同时,NetBackup服务器会找到这些数据或目录并且帮助客户进行恢复。EMC Legato可以实现企业级的数据备份和恢复,同时实现对数据的管理。

通过使用备份软件可以为生产系统的数据做备份,当生产数据因各种原因损坏后还有可用的备份数据进行数据恢复,从而提高了数据的安全性和保证了业务系统的连续性。为了让大家对备份软件的运维难点与故障处理有更深入的理解,社区组织了这次活动,在此邀请大家积极参与共同交流学习提高。

以下是本次活动的议题:

1.TSM备份软件实现数据级容灾的实现方式是怎样的?

数据容灾,根本思想是关键的业务数据保留多份备份(本地和远程)。 支持业务的基础架构还有许多其他东东,物理机/虚拟机,虚拟机管理系统,存储系统,实际的软件/中间件/数据库等。这些都好恢复,数据丢了就歇菜了! 要想提高可用性,实现容灾,提高RPO, RTO,也可以采用应用层方案,多活中心等,应用架构设计就考虑软硬件故障,site故障等情形,但代价很高,更多的软硬件,系统架构,运维更复杂等等,一般的企业不现实。 所以数据级容灾就是以尽量小的代价获得较高的收益!

TSM 大概可以有几种方式:

云备份池:

最新的7.1.6支持 复制数据到云备份池(openstack, amazon, clearsafe), 复制到云池的数据在线去重/压缩。

磁带拷贝池:

传统方式,主池定期做备份到拷贝池(一般每天),拷贝池磁带check out后运往本地或远程灾备中心。 相似的还可以采用export to tape, generate backupset to tape.

企业多站点,多个TSM Server的时候:
TSM server之间可以repl node/protect stg(6.3+以上server),export to server将数据存在别的server中一份。

RPO/RTO 跟你使用的备份方式密切相关,比如采用磁带拷贝池,晚上对主池备份一次,运到灾备中心,RPO只能是恢复业务到一天前状态。那我们采用云备份池/TSM server之间可以repl node/protect stg,设定每天更频繁的数据复制,则RPO是以小时计,整个业务系统可以恢复到几个小时前的状态。

RTO 则跟实际恢复数据时间(磁带恢复速度), 你的网络带宽(repl node方式,云备份池),从灾备中心运回磁带的速度,恢复其他基础架构的时间密切相关。

2.备份软件常见的故障有哪些,如何处理这些故障?

备份软件的日志一般是第一手判断问题的重点。多数成熟的备份软件都会有详细的日志来说明相关的错误。

其次就是确认备份的环境、网络、系统状态、备份服务这些。

很多原因都会导致tsm备份失败,查找原因需要看日志

数据库:api的log,tsmserver的log
文件:ba的log,tsmserver的log
RC 106,一般是日志权限的问题,找到需要的日志,加上权限。
RC 12,介质mount不可用,一般是TSM调用带库的时候出现问题,查查驱动器和path,看看存储池的最大可用scratch数值;如果是磁盘,看看磁盘的文件系统权限。

第一次启动调度的时候,如果调度进程未启动,可能是因为password生成参数没设置好,或者没有手动的登录一下客户端。

ANS0102W,语言包的问题导致dsmc登录不了,将/opt/tivoli/tsm/client/lang/en_US目录内所有内容,拷贝到/opt/tivoli/tsm/client/ba/bin目录下试试。
ORA-19554,动态链接库的问题可能大些。
挺多的,遇到就记下来,可能就好了。

3.在运维这些备份软件的过程中您有哪些独门绝技向大家分享的?

tsm的所有错误信息都保存在活动日志里,但活动日志不仅信保存错误信息,也会保存系统中所有行为的相关信息:

查看一小时以前的所有日志:
query actlog
如查看昨天8点以后的所有日志
query actlog begindate=today-1 begintime=08:00:00

查看日志中有关nc_ora节点的相关信息,可以加上search参数
query actlog search=nc_ora
查看TSM服务器中的日志信息:
query actlog originator=server

大家在调试和运维备份软件时有哪些技巧可以来分享一下,大家交流学习。

个人觉得分析备份问题首先是分为Server端和client端,如果日志直观显示问题所在,则直接处理问题即可;如果一个备份失败了,但是日志模糊不清,无法具体定位问题时,首先是判断服务器是否可用,如果当前还有其他备份可以执行,基本可以判断服务器可用性;接下来需要判断存储介质可用性,如果当前的数据备份存储池仍有其他备份作业写入成功,那么存储介质可用;接下来具体分析该客户端,如果是数据库备份,则可以尝试在该节点发起一个文件备份实施是否链路可用,介质可用,通信正常;如果是一个Lanfree的节点,则先注销lanfree发起备份,判断是否是由于LANFREE的path问题,引起的故障。

常见的错误都是累计出来的,比如oracle备份首次出现7011 RC106,那么改一下日志权限,基本能成功;

4.当备份软件出现无法备份或是备份失败的情况应该如何诊断出现问题的原因并处理问题?

TSM的话,文件备份直接查看日志dsmsched.log文件,数据库的话查询对应的日志,日志一般都是在dsm.sys对应的调度内容上指定的。如果日志直观的话,可能直接会显示出问题所在,比如文件正在使用使用跳过,或者超出存储空间等报错,或者归档日志不连续找不到归档,数据库非归档失败等等;

如果日志表述无法直接定位问题,那么需要分析该问题是服务器端还是client端的问题,如果其他备份作业成功完成,那么备份服务器基本判断可用;之后看存储池,发起测试备份写入该存储池,如果可行则存储介质基本判断可用,带库路径驱动器路径可用;如果是数据库备份,则尝试发起文件备份,如果文件备份成功,那么基本判断是该节点的数据库备份问题,那么可以尝试重新执行配置,和检查配置文件的方式,判断问题。

5.TSM对比NBU、Legato这几个备份软件各有哪些优势,适合哪些应用场景?

TSM没有实际使用经验,但看同行分享的一些案例,确实概念定义比较繁琐,同时涉及的面非常……太……广,但(熟练后)使用起来很方便的。一名专业的TSM大能,绝对称得上运维的一支标杆了。

NBU可以看做TSM的简化版(个人理解),功能可圈可点,集成的一些自家功能也是很方便。NBU的一些配置流程可以完全系统的走向导,出问题可能性比较少,抛出的报错也比较利于新人排查。不过veritas这几年都没消停,分分合合不知后路如何~

CV基本靠界面操作,简洁明了(前提是不出问题),配置维护的学习成本低,但命令行少,后台不明晰(大部分报错全代码),而且WINDOWS SERVER在超大型的备份系统下,高并发备份真的是让人想哭。。。

Networker可以看做这几款产品的折中,界面上可以玩,后台也可以玩,常规操作可以完全后台命令实现。之所以倾向于Networker还有一个原因是后台debug全开放,个人熟练之后(除开BUGFIX)完全可以不需要原厂。同时Networker和自家产品的一些特色功能也是很赞的,比如和DD结合的克隆,直接点到点传输。但NW 8.x后各种大大小小的bug实在太多了(对新手很不友好)~~

对于超大型的IDC备份(周期备份数据100T以上),目前见过的、能撑起来、效率说得过去的只有TSM、NBU、Networker,CV乏力(并不是说它不好,只是windows server的一些制约影响)。

对于个人的话,备份软件的选择多看你的习惯,喜欢自己动手折腾的,这几款备份软件都可以。如果只是兼职备份,不想花太多时间,那么Networker一定不要选。

6.TSM 备份大批量小文件是否有更好的办法?

关于大量碎片文件的备份,目前行业内没有特别直接有效的方法,即使是成本较高的存储级别复制,也难以达到长期保留的目的。此前借交流会和国外的容灾和业务专家谈及这一点的时候,他们也表示在国外过去的十几年里也存在这种问题,但现在已经想办法规避了,规避的原则是正规化业务、优化小文件的存取方式,减少小文件的数量。国内之所以这个有问题尤为明显,很大原因是业务模式不规范且固定,很难整体优化改善,加上是历史问题,动刀起来很麻烦。

个人维护过的备份容灾系统,也有财大气粗的大企业直接拿存储来做复制,利用两套存储来达到长期保留的目的。但一般类似影像录音文件或者话单文件,几乎都是要永久保存的。从长远眼光来看,这种做法维护成本高,且效率不是特别理想,属于高投入低回报的措施,可总归是一种解决办法吧。

再者,很多公司考虑NDMP备份,虽然说这个做法屏蔽了一部分影响备份效率的因素,但归根到底,根本原因没有完全改善。相对于直接拿存储做复制来说,算的上一种低廉但有效的措施。

最次,一些对安全性完整性要求不太高的公司,干脆搞一套NAS让这些头疼的碎片文件自个儿乐,不备份!这一种做法,哈哈,算破罐子破摔了。

最后说说我推荐的做法,我们先从根本讲起:

1,海量小文件为什么让人头疼?
望文知意,文件小、数量多,那么读写效率必然低,积少成多之后问题越放越大,最后就是一块烫手的山芋。

2,常规的三种做法问题在哪儿?
存储复制,成本高,效率低,文件系统大了,仅这一项保存方案就是一笔不小的开支,但高投入也并没有带来多大的回报,勉强是完成了任务。
NDMP备份,治标不治本,但成本较低,对于中小型公司来说,不失为一种有效的做法。
NAS保存,数据的安全性完整性低,用句调侃的话来说--“你就自个儿偷着乐吧,乐出事来就拜拜了”。

3,改善方向?
从根本原因入手,小文件,那就聚合成大文件;海量,那就分门别类方便读写,然后尽可能避免和减少数量。说到底海量小文件还是早期业务不规范导致,现在规模大了也不好改善。但对于这个问题改善的方向,只可能是优化文件的存取方式,尽可能减少其规模。

4,个人推荐的折中做法
此前一直接触运营商的业务系统比较多,运营商的话单、录音和保险里的影像文件差不多,所以基本可以混为一谈。

运营商的话单和录音文件,大的话一天上TB,小的也有500G上下,存取方式也没有规律。后来建议客户改善存取方式,话单按天按系统类别存放、录音按业务系统通道划分。备份方面,当天备份昨天的话单和录音文件,因为优化了存取方式,所以备份前对各类文件tar打包。相比与直接备份小文件,利用主机的高性能来tar包形成大文件,大大降低了备份和恢复的时间,提升整体效率。备份完成了tar就可以删除,也不会额外占用空间。恢复时,只要定位了系统类别就可以快速找到需要的文件,恢复整个tar包的速度会非常快,解压的效率全压在主机上,相对于传统做法也改善不少。

解决整个问题的思路,源于二叉树的快速存取模型。参考二叉树模型,把海量小文件细分,方便查询和业务复验要求。然后从最高深度将一定规模的二叉树父节点和子节点全部打包,这样就能形成一定数量大小的二叉树节点,这样在不改变业务系统整体架构的情况下,也改善了海量文件的备份容灾问题。

有兴趣的话,可以参考一下,个人认为还是比较物美价廉的解决方案。

7. TSM在恢复oracle时,怎么设置rman的备份集和备份片,来使恢复效率更高?

在默认情况下,一种类型的文件在备份集中都会存成一个备份片段。不过考虑到如果文件较大,生成的备份片段可能也较大,甚至超出操作系统限制(不稀奇,比如Windows平台下FAT32文件系统,单个文件最大不能超过4GB),在你真正创建备份策略之前,备份片段文件大小显然也得在考虑范围之内。

RMAN在分配通道时有一个参数MAXPIECESIZE,就是专门用来指定备份片段大小的,例如,备份SYSTEM表空间,指定单个备份片段最大不能超过10MB

单个备份集的最大值可以在执行备份命令(或分配通道)时通过MAXSETSIZE参数指定,比如:

RMAN> BACKUP DATABASE MAXSETSIZE=100m;

MAXSETSIZE参数指定的是单个备份集的最大值,与备份片段无关,不过默认情况下,一个备份集对应一个备份片段,因此也相当于指定了备份片段的大小,但是直接指定MAXSETSIZE参数限定备份集大小并非在所有情况下都适用,如果要备份的数据文件中,任意一个数据文件超出了指定参数值,则备份就会失败(前面示例命令执行肯定失败,因为默认情况下SYSTEM表空间数据文件就接近300MB)。因此,对于在实际应用中需要限制生成文件大小的情况,更多还是会通过MAXPIECESIZE参数限制备份片段,而不会直接限制备份集。

8.虚拟带库里有这样一盘磁带,在tsm下看是空的scratch状态,在EMC控制台下看到是满的?

1.查看带库日志和备份软件相关日志信息;
2.TSM备份配置参数:
如果collocation的参数设置不是no。则可能的参数值包括:filespace,node,group。

如果设置为filespace,则磁带选择的顺序是:
1. 优先选择已经备份同一文件空间数据的磁带;
2. 已经定义的空白磁带;
3. 定义为scratch的空白磁带;
4. 包含同一节点数据的已经使用过的磁带;
5. 空间最大的一盘已经使用过的磁带;

如果设置为node,则磁带的选择顺序是:
1. 包含同一节点数据的已经使用过的磁带;
2. 已经定义的空白磁带;
3. 定义为scratch的空白磁带;
4. 空间最大的一盘已经使用过的磁带;

如果设置为group,则磁带的选择顺序是:
1. 优先选择已经包含来自客户端所属的collocation group的备份数据的磁带;
2. 已经定义的空白磁带;
3. 定义为scratch 的空白磁带;
4. 空间最大的一盘已经是使用过的磁带。

面对上述例子中情况,用户可以考虑下列方法来跳过需要等待的60分钟。

在checkout命令执行完后,修改磁带A0000的access属性为unavailable。命令如下:
update volume A0000 access=unavailable

9.备份VCener的解决方案?

通过VMware VADP接口,将数据映射并和TSM API(TSM for VE)结合后,直接集中备份到备份设备中存放。

采用持续增量备份,就是TSM的永久增量备份技术,可以以最合理的方式减少备份窗口,冗余数据和备份设备介质的资源使用率。

只有第一次是全备份(去掉了VM的空块空间)。

后续备份,全部采用持续增量备份,自动启动VMware的CBT(changed Block Tracking)功能,并跟踪块的变化进行仅增量备份。

10.云环境下的备份规划有哪些新思路和新解决方案?

在云计算环境中,传统的备份技术遇到了需要安装备份代理、空白数据占用空间、数据冗余度高和备份颗粒度大等问题。基于此,研究了通过VADP接口,实现无代理备份、数据块修改跟踪、文件级备份恢复、重复数据删除、vCenter集成及应用感知等的云计算环境的备份软件技术,并验证了重复数据删除对数据块修改跟踪技术的有效性,为云计算环境的数据备份提供了有益的参考。

1.随着信息化的发展,各种业务系统已经成为大型企业日常生产不可或缺的一部分,这些系统所产生的数据也成为运营商的核心资产。在软硬件处理能力越来越强的现在,电信运营商的IT系统呈现出集约化、云计算化的趋势。

对于电信运营商,大部分业务系统是由各省级单位独立建设,互不兼容。在市场竞争激烈、成本要求苛刻、精细化管理成为企业必需的情况下,三大运营商不约而同地选择了集约化发展的道路。业务的变化推动IT系统的集约化,运营商纷纷尝试将分省建设、管理的系统集中到全国几个大型中心。集约化后的IT中心带来了数据的高度集中,对系统备份和恢复的速度要求更加苛刻。

与集约化同时进行的是IT系统“去IOE”的进程。去IOE即在服务器设备上,使用标准化程度高的X86服务器逐渐取代高可靠性、生态系统相对IBM Power小型机乃至所有的小型机在核心系统的使用。去O即从小型业务系统开始,使用Scale out架构的开源数据库逐步消除Oracle数据库在运营商的垄断地位;去E即在数据存储领域使用更为廉价的存储方式代替昂贵的高端EMC存储。去IOE在节省成本、降低对原厂依赖的同时,也带来了对业务系统、数据库及业务数据可靠性的忧虑。

云计算化是使用虚拟化基础架构代替过去孤立的、烟囱式发展的传统IT架构。云计算是在由服务器、存储、网络交换机等硬件的基础上增加了虚拟化层和云层。其中,虚拟化层屏蔽了硬件的差异性和复杂度,为云层提供标准化、可灵活扩展和收缩、弹性的虚拟资源池;云层可以调配硬件资源池,为应用系统提供虚拟硬件。云计算化在增加灵活性的同时,也更来了更多的可能的故障点。

集约化、去IOE化、云计算化的IT系统带来成本节约、灵活度更高的同时,也为应用系统和数据的可靠性带来了更大的挑战。为了保障IT系统安全,需要建立稳定、高效的备份系统,将应用系统和数据备份多份后,在异机甚至异地存储。备份系统可以保证在应用系统出现问题的情况下能够回退到正常状态,是企业IT安全的最后一道防线,需要引起高度重视。

2.传统IT基础下的备份技术

2.1 传统备份对象

在传统IT基础架构下,备份的对象主要针对操作系统、数据库和文件系统。

操作系统是应用系统的基础,其备份技术也是备份的难点。操作系统备份包括系统备份和系统恢复。系统备份由文件备份、系统数据一致性及系统环境等技术组成。操作系统备份时,系统文件、环境变量等参数会不断发生变化,有可能发生相关文件备份时间不同而导致系统故障的问题。为了保证一致性,需要对备份过程中的I/O(Input/Output,输入/输出)进行备份,在系统恢复时将备份过程的I/O操作重新写入操作系统,从而使系统状态与备份结束时间点的状态一致,降低了系统崩溃的风险。系统恢复在异机恢复方面有可能面临着设备驱动不一致,从而导致恢复后的系统无法正常使用的问题。

数据库备份不仅需要备份数据库中的用户数据,还需要对重要的数据库组件如数据文件和控制文件进行备份。数据库的备份可以分为静态备份和动态备份。静态备份是在系统没有事务需要处理时进行的备份作业,在备份期间不允许对数据库进行查询、插入等活动。静态备份可以很好地保持数据的一致性,但同时降低了数据库的可用性。动态备份可以在用户事务发生的同时进行,允许在备份期间对数据库进行存取、修改等操作,但这种方式无法保证副本数据的有效性,需要记录下备份期间对数据库的存取等活动日志。数据库恢复时,需要恢复副本和备份期间的日志才能恢复到正确的状态。

文件系统备份可以通过文件系统定位文件所在的页,然后备份所找到的文件。由于存储在磁盘中的文件的页并不一定是连续的,因此在恢复的过程中磁盘需要不断定位,从而导致磁盘负担较大。在文件系统备份中,运营商的话单文件体积小但数量非常多,其备份是一大技术难题。

2.2 常见备份方式

在实现生产中,通常采用以下方式进行备份:

(1)使用数据库自带备份工具备份。对于Linux下的Oracle数据库,可以编写Rman脚本备份数据,再通过Crontab配置定时复制命令,将数据库备份文件复制到磁盘阵列。对于MySQL,可以使用自带的mysqldump工具,实现基于InnoDB的热备份。

(2)使用操作系统自带工具。Linux操作系统中常使用dump和restore命令来实现文件系统的全备、增量备份和差异备份等备份方式,Windows Server下也自带了Windows Server Backup的备份和恢复工具。

(3)基于存储的硬件备份。存储设备是使用硬件来实现数据的存储、备份与恢复,速度较快。通过存储,还可以使用更高级的存储技术,如快照、镜像、重复数据删除等功能。同一厂商的存储产品往往具有远程镜像的功能,可以将本地备份数据通过同步或异步的方式自动实现异地备份。然而不同存储厂商间的硬件备份技术使用不同的技术标准,互不兼容,从而导致不同品牌的存储不能实现硬件的远程镜像。运营商的核心数据经常需要保留三份以上的异地备份,就需要在三个地点都使用同一个厂商的存储设备,这也成为基于存储的硬件备份的一大阻碍。

(4)基于备份软件。备份软件集成了各种数据库、文件系统的备份等功能,又具备了镜像复制、快照、重复数据删除、数据校验、SAN(Storage Area Network,存储区域网络)备份等高级存储功能。备份软件从软件上屏蔽了硬件设备的差异,可以统一管理服务器硬盘、磁盘阵列、虚拟带库以及物理带库等存储设备。同时,备份软件也可以实现对不同操作系统(Windows、Linux、Unix)、不同数据库(Oracle、SQL Server、MySQL)的备份。通过备份软件,系统管理员不需要对不同的操作系统、不同的数据库、不同的存储设备和服务器各自编写自动备份脚本,可以在统一的界面上通过命令行或图形化界面集中管理备份设备、存储设备、备份策略。因此,备份软件也是核心IT系统中常用的备份方式。

(5)备份一体机。随着一体化设备的发展,备份软件厂商纷纷推出集成了备份服务器、存储、备份软件的备份一体机设备。这种备份一体机可以在用户快速部署,大大方便了异地数据备份。

2.3 备份软件

备份软件架构如图1所示,主要由备份服务器、备份代理、存储服务器、Web服务器组成。

备份服务器可以自动进行备份作业的调度,通过指挥备份代理和存储服务器共同完成备份、恢复任务。备份服务器维护着Catalog数据库,在数据库里存储备份恢复作业的信息及物理设备相关的信息。备份代理一般是安装在需要备份的主机中,调用相关系统的接口。在备份作业发起时,数据由备份代理读取并传输到网络。对于不同的备份对象,往往需要安装对应的模块。例如,为了分别备份Oracle数据库、SQL Server数据库,就需要在对应的主机中分别安装支持Oracle数据库模块和SQL Server数据库模块的备份代理。对于不同的操作系统,也需要安装相应的备份代理。存储服务器可以将关键数据存储在存储设备,如磁盘阵列、虚拟带库、物理带库,负责存储中备份数据的读取和写入。Web服务器为管理员提供Web管理界面。目前主流的备份软件不仅有商用的IBM TSM、CommVault、Symantec NetBackup、HP DP等产品,而且还有开源的备份软件Amanda、Bacula等产品。

3.云计算对传统备份技术带来的挑战

云计算技术在IT基础建设的引入,可减少硬件资源浪费,提高系统部署的速度,但也为备份带来了新的需求。

(1)虚拟机备份代理。在存储中为虚拟机分配的空间,以虚拟机文件格式方式如.vmdk存储,虚拟机操作系统文件、用户数据放置在这个vmdk文件中。如果按照传统备份方式,要备份虚拟机中的系统和用户数据,就需要在每台虚拟机中安装备份代理。这种方式在占用大量的存储资源的同时,发起备份时也会占用大量的计算资源,从而影响虚拟机性能。

(2)空白数据的空间占用。在分配虚拟机时,精简模式下的虚拟硬盘根据所需数据量的大小占用存储空间。虚拟硬盘空间随虚拟机数据量增加而变大后,在虚拟机中删除的数据并不会减少虚拟硬盘的空间大小,这样就造成大量空白数据占用了存储空间。如果对虚拟机的备份只是简单复制虚拟硬盘文件,就会出现备份中的有效数据少的问题。

(3)数据冗余程度高。在虚拟机中,往往安装大量相同的操作系统、应用程序,这部分数据高度相同,如果直接通过安装在每台虚拟机中的备份代理来备份数据,则会造成大量的冗余,浪费存储空间。

(4)备份颗粒度过大。通过虚拟化平台自带的虚拟化接口可以备份和恢复整台虚拟机,但往往需要备份的数据只是虚拟机中的部分用户数据,而不是完整的虚拟机。虚拟机级的颗粒度会拖慢备份恢复速度,消耗大量的存储空间。此外,这种方式也无法感知应用,难以保证数据的一致性。

基于上述情况,传统的备份方式已经不适应云计算时代的数据备份,亟需针对云计算的数据备份技术。

4.云计算环境的备份技术

4.1 基于云计算的备份技术

在云计算环境下,调用VMWare在数据存储方面的接口,可以有效地解决虚拟机的备份难题。

(1)无代理备份。VMWare开放了VADP(vStorage APIs for Data Protection,用于数据保护的虚拟存储应用程序编程接口)的数据保护存储接口。备份软件调用VADP,即可与集成在vCenter中的vStorage for Data Protection模块通信,对每台虚拟机都实现不需要第三方备份代理的备份,从而减少备份对虚拟机计算资源的消耗。

(2)数据块修改跟踪。VMWare提供的VMKernel级技术CBT(Change Block Tracking,数据块修改跟踪)可以判断在最后一次快照后是否有虚拟机数据块被修改,并标记被修改的数据。备份软件调用VADP接口,即可备份被修改的增量数据,而不需要对虚拟机文件做完全备份。

(3)文件级备份恢复。VMWare FLR(File Level Recovery,文件级恢复)提供了浏览和装载虚拟机备份数据的功能。通过备份软件,调用VADP的FLR功能,可以实现对虚拟机的文件级颗粒度管理,而不需要做虚拟机级别的备份。

(4)重复数据删除。传统的重复数据删除常使用固定数据块或者固定长度数据段等技术进行重删,但这种方式存在着即使数据集发生了非常小的改动,都会导致整个固定长度数据段的更改,从而不被识别为冗余数据。对于虚拟机的重复数据删除技术,常采用可变长度数据段。VMWare VDP(vSphere Data Protection,vSphere数据保护)技术能够分析数据集的二进制数据结构,确定数据段的边界,且适用于不同类型和体积的文件,从而实现智能化的重复数据删除。

(5)vCenter集成。备份软件以vCenter插件的形式集成到vCenter的管理界面中,方便vCenter管理员管理虚拟机的备份,而不需要到专门的备份软件中处理。

(6)应用感知。对于虚拟机中安装的SQL Server、Exchange、SharePoint、Active Direct等应用系统,可以通过在这些应用所在的虚拟机中安装VDP客户端,即可实现来宾级细粒度的管理,从而实现对虚拟机中的应用感知。

4.2 重复数据删除

对VMWare vSphere虚拟化环境,使用重复数据删除技术,对其中的30台虚拟机总共1053GB容量的虚拟硬盘进行全备份。在自动识别并剔除空白空间后,需要备份的数据只剩下虚拟硬盘数据的76.5%。而在使用重复数据删除进行消重后,实际写入存储空间的数据只有源数据的29.4%,因此实际重删比为70.6%。重复数据删除技术可大大减少虚拟机备份所需要消耗的存储空间。初次全备份需要数小时的时间。在虚拟机进行数据读写操作,增加少量用户数据,此时再做全备份,备份时间可缩短到数分钟。这是由于调用了VMWare的CBT技术,使备份数据仅为修改的部分数据,从而加快了备份速度,减少了网络流量和备份数据量。

11.由于TSM使用命令比较多,不利于管理员查看错误,Web端对于TSM的管理是否有所增强?

Tivoli TSM产品功能详述

TSM(Tivoli Storage Manager) 是一个企业级的Client/Server结构跨平台网络备份、恢复及存储管理软件。TSM Client主要功能是向TSM Server提供需要备份的数据,或向TSM Server索取已备份数据及归档数据以便Client恢复数据。TSM Server负责管理TSM Client的备份数据、备份策略及管理连接在TSM Server上的各类存储产品。

TSM自动备份和恢复

一旦整个备份系统设置完成,每个应用系统的服务器会在指定的时间把需要备份的数据送到TSM服务器中集中存放。如果需要恢复数据,TSM Client端只要通过非常简单易用的图形界面或由应用程序发出指令指出恢复哪些个对象文件,TSM Server自动从磁带库中取出文件,交给TSM Client。如果备份磁带不在磁带库中,TSM Server提示系统管理员插入某盒磁带。

TSM是一个彻底的在线备份软件。对数据库,TSM通过TSM Connect Agent备份正在打开的数据库。对一般文件系统的文件,TSM的Client端能够备份打开的文件,甚至能备份正被修改的文件。当备份TSM遇到需备份的文件正被改动时,有四种处理方式:

  • 不备份,同时在日志中留一个标记;
  • 马上备份
  • 重试数次(次数由用户预定),如文件仍然在修改,则不备份,记日志;
  • 重试数次(次数由用户预先指定),最后一次无论文件静止或仍然在改动,都备份该文件。

TSM比同类备份软件考虑的更多的是数据的恢复能力。TSM的观念是:备份的目的就是恢复。所以在备份软件的评测中,备份速度TSM的优势并不明显,而恢复速度往往是其他软件的数倍。

TSM 这种惊人的恢复速度及其他许多独一无二的功能主要依赖于TSM强大的内核,TSM的引擎是一个关系数据库。迄今没有任何一家其他备份软件是采用关系型数据库作核心的。关系数据库的处理能力和搜索速度是TSM性能超越其他采用索引文件作为引擎的备份软件的主要原因。TSM完善的介质管理能力也得益于这个数据库引擎。

TSM备份和恢复过程的容错性

TSM是唯一采用数据库作为核心的备份管理软件,每个备份对象都作为一个交易 (Transaction)来处理。因此TSM具有很强的容错能力,TSM的传输数据原则是:尽量避免不必要的重复数据传送占用网络带宽。当某个备份或恢复过程因为网络中断或机器故障而意外终止,下次重新递交该备份或恢复进程时,TSM会从中断处继续传输,而不是从头开始(许多备份软件都必须从头开始重做)。原因是TSM对每个对象备份完成与否都有日志记录,就象银行系统对每笔交易完成与否都有记录一样。

TSM的永远增量备份

TSM 支持全盘备份和独一无二的“永久增量备份”方式。永久增量备份是指:初始时做所有数据文件的全盘备份,以后只备份新的或改动过的文件。这种方式减少了备份时间和所需的存储容量,减轻了网络负担。这种方式的原因是TSM把每个备份对象作为一个交易,记录在它的关系数据库中,每个备份对象对应文件系统的一个文件。当用户需要恢复文件系统时,TSM找到所有属于该文件系统原备份对象,交给用户。所以,TSM能够做永远的增量备份。

TSM的介质管理能力

TSM 对备份和归档数据分别管理。因为归档数据保存时间比备份数据长,而且备份数据有‘版本’,归档数据无版本。‘版本’就是同一个数据对象的多个备份 copy,例如,记录销售情况的文件每天都在改变,如果每天做备份,那么每天的备份就是一个‘版本’。用户可以根据实际业务需要,保留必要的‘版本’数。 TSM能够自动清除过期的备份版本和归档数据。

TSM在介质管理中采用了独一无二的“磁带集中”和“磁带重用”技术。“磁带集中”使每个客户机的每天的备份数据都对应放在一盒或一组磁带上,使得TSM能够用最少的磁带数做恢复。这是一种迅速、可靠的数据恢复方式。

“ 磁带重用”的目的是使磁带库或光盘库介质自动轮转,完全实现备份、恢复的无人值守。原理是:当介质上的过期数据越来越多并达到一定限度时,比如介质上 80%的数据都过期了,TSM会自动把数个这样的介质的残余数据整合到一个介质中,而其它介质重新进入新的介质轮转中去。所以,如果用户有足够的存储容量,TSM可以做到真正的‘零管理’。

TSM能够自动跟踪所有介质的去向和使用情况。TSM不仅自动管理磁带库、光盘库中的介质,还能跟踪放在磁带库、光盘库外的介质和保留在异地的备份介质。当恢复需要这些介质时,TSM会提示管理员到何处去取标签为xxx的介质。

TSM本身具有完善的自我保护和恢复机制。配合TSM的灾难恢复,可帮助用户在计算机系统发生灾难性事件后迅速恢复系统和数据。这在后面有更详细的说明。

数据库备份的考虑:

数据库的备份主要考虑备份是在线热备份还是冷备份。数据库的存储空间是建立在文件系统还是裸设备上。

建立在裸设备上的文件无法通过操作系统的文件系统来访问,而大部分应用程序包括TSM都是通过文件系统来访问数据的。数据库热备份是在数据库打开的情况下做的,所以在备份前一定要保证数据据库的完整性。失去完整性的数据库是无法恢复的。冷备份是在数据库正常关闭后做的备份,所以不需要考虑完整性(数据库已经是完整的)。

如果数据库存放在文件系统中,又只要做冷备份。非常简单,使用TSM的Client自动备份(或用户选定)相关文件即可。备份Oracle就采用这种办法。同样,如果Informix和Sybase基于文件系统,需做冷备份也采用这种方式。

如果做冷备份的数据库基于裸设备,或者需要热备份,则需要数据库工具来实现, TSM提供对以下应用的在线备份能力:

Lotus Domino、DB2、Oracle、Informix、SAP R/3、Exchange、SQL Server等
而且,Tivoli提供对应用的备份将可以充分利用到Tivoli对SAN的支持,应用可以支持通过SAN进行在线备份和恢复。
灾难恢复功能
TSM的Disaster Recovery Management(DRM) 选件能够帮助用户迅速恢复系统。

优点:

在各类灾难恢复方案中,是最全面及简单易行的方案之一
灾难发生后能够全自动恢复TSM服务器
自动生成可执行描述文件,准确、迅速恢复TSM服务器
为系统级的灾难恢复提供所需信息及步骤的详细描述
管理和跟踪TSM数据库和存储区间备份卷,智能化减少人为错误为PC机的硬盘提供物理级镜像式恢复
大幅度减少系统管理员在容灾方面的时间投入详细地指导操作人员如何一步一步恢复系统

好的计划是容灾的关键

许多企业机构都认识到数据备份是保证业务正常持续运行的重要部分。如果缺少了正确的数据保护,那么设备的故障、人为错误或自然灾害都会导致关键任务数据的丢失。但是,数据保护工作却变的越来越复杂,原因是关键性数据的存储越来越分散,数据分布在不同的地理位置或不同的组织部门中。

即使已经做了安全守护措施,那么当灾难发生后,在一个大型组织中需要多少时间才能彻底恢复数据呢?

答案取决于多种因素。灾难发生前,备份是否不折不扣的执行;如果日常有信息系统的恢复计划存在,该计划是否始终保持更新;如何在灾后迅速找到所有本地或异地的备份数据;如果灾难摧毁了服务器和工作站,那么这些设备的软硬件配置环境必须能够重新建立起来。

在很多情形中,实施恢复任务的工作小组往往不熟悉整个企业计算环境的结构,因为他们并没有参与当时结构的设计和初始化安装设置。

在灾难发生后的混乱中,管理员很难做到周全安排、井井有条的恢复系统及数据。因此,他们需要一份无懈可击、条理清晰的恢复指导书,TSM的灾难管理功能(简称DRM)能够指导用户如何操作来迅速恢复企业范围内的各种数据。

DRM管理自动恢复所需的每个细节

自动、准确的DRM功能帮助用户保护宝贵数据的安全性。在TSM管辖内的数据,都能通过DRM自动策划、准备及制作备份恢复计划,一旦DRM生成了计划文件,所有服务器上最新的相关信息都被收集起来,以备恢复。

如果灾难发生,DRM提供恢复步骤的详细文档,可执行的描述文件自动恢复数据、重建环境。DRM使得企业可以很快回复正常运转。

DRM智能化管理和跟踪备份介质的转移。帮助管理员决定哪些介质本地保存,哪些介质需要异地保存。当恢复灾难时,DRM帮助用户迅速找到所有需要的介质,无论这些介质是在本地或运输途中或在异地的保险柜里。

TSM客户端追踪管理功能帮助系统管理员了解哪些系统被灾害摧毁,以及这些机器所需要的软硬件,以便用户决定需要重新定购哪些设备来替换损坏的设备。

其他DRM记录的重要信息包括:需要恢复的各台机器的优先级;相关人员的连续方式等

DRM简化了计划和稽查过程

DRM自动收集制定恢复计划所需要的信息,并自动执行灾难恢复过程中的一些重要步骤,从而节省了系统管理员大量的时间。

许多机构需要定期测试容灾方案以确定其可行性,DRM集中式的管理和维护便于检查,而DRM清晰的步骤使得无论是全局测试或局部测试都简单易行。

12.请问TSM 怎样实现归档SQLServer 2012 AlwaysON环境的数据库的备份?

SQL Server2012中新增的AlwaysOn是一个新增高可用性解决方案。在AlwaysOn之前,SQL Server已经有的高可用性和数据恢复方案,比如数据库镜像,日志传送和故障转移集群.都有其自身的局限性。而AlwaysOn作为微软新推出的解决方案,提取了数据库镜像和故障转移集群的优点。

因为always on 环境下,数据文件都到了 cluster节点对应的存储池中。

现在我想到的另一个方法就是单独通过SQL备份出文件,然后文件 归档到TSM
上面这种备份方式需要测试数据的完整性,确认数据是否可用。

13.带库中磁带寿命大概多久,一盘磁带反复回收重写会有什么影响吗? 带库驱动器三天两头提示需要清洗该如何解?

磁带终究是一种易耗品。和周围的环境,磁带本身的质量。驱动器等都有关系。我们曾经遇到过一个驱动器有问题。会加速磁带的损坏。基本上这个驱动器在的时候两三个星期就会出现一盘坏带。

磁带属于易耗品,容易坏,和保存方式,空气的湿度、温度使用次数都有关系,一般三年左右就得更换,对于需要无限保留的数据可以使用光盘塔方式保存!

磁带寿命的理论时间确实没有什么指导意义。大家都知道电子产品也好。磁带也好。说怀就坏。如果用了五年,还是建议做出准备来更换。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

13

添加新评论4 条评论

xiangxiang1999xiangxiang1999系统架构师, 北京某技术公司
2023-08-02 21:15
非常不错,谢谢分享
按兵补洞按兵补洞系统工程师, 北京神州新桥科技有限公司
2019-12-23 15:33
非常不错的资料
wsbj123wsbj123软件开发工程师, SXYZ
2019-01-22 09:54
不错~
aqwaqwaqwaqw项目经理, 中软国际 专业服务集团
2017-10-30 10:56
不错的文档,谢谢分享!
Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

相关资料

X社区推广