数据备份与恢复策略建议

  4.1 备份与恢复方式及数据流 XXX业务系统的日常备份操作由备份系统自动完成,操作人员按照要求在备份服务器上制定备份策略,全网的备份由TSM备份服务器统一管理。各客…

 

4.1 备份与恢复方式及数据流

XXX业务系统的日常备份操作由备份系统自动完成,操作人员按照要求在备份服务器上制定备份策略,全网的备份由TSM备份服务器统一管理。各客户端也可以自行手工启动备份。TSM备份服务器(包括主服务器和共享服务器)的数据(文件和数据库资料)直接进入磁带库;各客户端的备份数据由网络传到备份主服务器,进入带库;如果采用LAN-Free备份方式,客户端的备份数据则不经过局域网和备份服务器,而是直接备往带库;对于一些小文件,我们可以先将这些小文件备份到TSM备份服务器的本地硬盘存储池中,待达到一定百分比时,在一次性迁移到带库中;而对于一些大文件,可以直接备份到带库中。这样可以大大提高数据的备份效率,提高存储设备的利用率。为提高备份质量、保证数据安全,可以采用TSM软件的自动的副本存储池复制功能,同时进行备份复制,一份近线保管,另一份离线保管(所有管理均由备份软件完成)提高系统容灾能力。

4.2 文件系统备份与恢复策略建议

4.2.1 备份策略(永久增量备份)

XXX业务系统有很多数据保存在文件系统中,对于文件系统的备份,TSM采用业界最为先进的永久增量备份方法,即:除了第一次需要进行全量备份之外,以后每次都进行增量备份,而无须进一步的全量备份,在恢复的时候可以一次性的恢复,从而能够大大减少需要备份的数据量,加快备份和恢复的速度;

除TSM之外,其他的备份软件基本上都采用某种完全、完全+增量或完全+差异的备份策略。TSM引入了一个新范例叫永久增量备份方法。当首次备份文件系统或计算机时,由于TSM以前未曾备份,所有的文件都将移动。当备份拷贝发送到TSM服务器时,每个文件单独存放在数据库中。文件名信息、所有者和安全信息、创建和修改时间,以及拷贝自身都放置在TSM服务器连续存储分层结构中。如果客户策略要求拷贝到磁带上,TSM数据库将记录磁带的条形码、起始块地址和文件长度。

在初始的备份后,将只考虑增量问题(不再进行完全拷贝)。每天将只移动上次备份操作后改变了的文件。并且,文件发送到TSM服务器后被单独存放在数据库中。当需要拷贝到磁带时,TSM服务器查询数据库,确定从前的拷贝在哪一个磁带上。一旦确定,将对该磁带进行再设置并把新拷贝附加在磁带末尾。这种对备份拷贝的收集都来自于同一台计算机或文件系统,于是形成了所谓的排列组。每天,改变的文件累加到排列组中(见图)。

图:永久增量备份

永久增量备份采用增量,提供了备份效率;采用排列组,提高了介质管理效率;准确地只移动期望的文件,提高了恢复效率。该方法最大的功效还在于:累加方法并不需要在一个完全备份后才能开始恢复过程,也就是说并不需要周期性地建立完全备份拷贝。而对完全+增量或完全+差异方法,无论是否改变,每周都要移动和存储几十亿字节的数据。有了永久增量备份方法,就不需要这样做了。于是客户节省了大量的网络带宽(LAN、WAN或SAN)、磁带介质和时间。

在TSM中,一个备份策略的制定可以让所需要被备份的客户端来共享,也可以在一个备份中心制定多个备份策略以满足不同数据备份的需要。Tivoli使用Domain的模式来进行管理,可以为每个Domain的备份和归档分别制定备份策略,包括:

  • 保留的版本数
  • 每个版本保留的天数
  • 到期版本的保留天数
  • 介质数据再集中的阀值
  • 。。。。。

4.2.2 恢复策略(一次恢复)

恢复操作的目标是让文件系统或计算机回到期望的某一时间点。常见的情况是客户期望的时间点就是最近某时刻。在永久增量备份方法下,完成一个完全的恢复操作只需告诉TSM服务器期望的时间点。利用时间点信息,TSM服务器查询数据库中文件集合,看它们是否在期望的时间点上。这些文件存在于同一个排列组上,通常也位于一个(或少数几个)磁带上。设置了正确的磁带后,数据库指定每个文件的长度和起始块位置。大多数现代的磁带驱动器都具有快速扫描功能,能迅速定位到期望的备份拷贝并执行恢复操作,这样只移动了期望的文件。用户可以把该过程看作完全系统操作中一个完整的恢复过程。该过程就象在期望的时间点做了完全备份一样(见图)。

 

图:时间点恢复

4.2.3 备份/恢复策略举例

备份策略的制定在很大程度上需要和XXX的实际备份需求相适应。下面结合Tivoli的永久增量备份技术来描述一个简单的备份策略:

  • 初始采取全备份策略,保留一份完整的数据。
  • 以后每天采用增量备份,选用增量级别。
  • 当出现恢复要求时,只需将全备份的全部数据加上前一天备份的增量数据恢复出来即可。
  • 经过一段较长时间后,可以再进行一次全备份。
  • 当要求恢复某些错误删除的文件时,系统会根据文件索引,找到删除文件的各个备份时间版本,从而帮助用户确认后从删除前一天的备份介质中加以恢复。

4.3 数据库备份及恢复策略建议

对于XXX的业务系统而言,数据库是核心数据组成部分之一,因此针对数据库制定一个良好的备份策略是至关重要的。对于数据库系统的备份工作,主要主要内容包括数据库系统备份和业务数据备份两个方面:

4.3.1 数据库系统数据备份策略

为了在主机、数据库、应用软件系统发生故障时,能够迅速、有效的使系统得到恢复,需要对主机、数据库、应用软件系统进行备份。由于主机、数据库、应用软件极少发生变动,所以它的备份策略也比较简单。

(1) 在主机、数据库、应用软件安装调试完毕后,将主机、数据库、应用软件系统的备份到磁带上。

(2) 在对主机参数、数据库参数、应用软件进行修改后,及时将主机、数据库、应用软件系统备份到磁带上。

(3) 定期对主机、数据库、应用软件系统进行全备份。这些全备份可以通过TSM的定时自动完成。

此外,TSM备份解决方案还可以提供额外的操作系统备份模块,应用系统备份模块等,能够对操作系统进行裸机备份,通过避免系统故障时重装操作系统来减少恢复时间。

4.3.2 Oracle数据库的备份与恢复

Oracle在归档模式下运行,利用IBM Tivoli Storage Manager for Databases模块调用RMAN进行在线的热备份,可以在备份时,对备份数据保存在不同的存储对象中,以满足客户容灾的要求,可以利用TSM的多线程的数据迁移、利用多个磁带驱动器同时读写提高其数据备份的效率。

针对Oracle的总数据量和增量数据量大小,我们可以利用Oracle的多达三级的增量备份机制,结合TSM强大的备份数据追踪寻址能力和介质管理功能,制定灵活的备份策略,实现全自动的备份数据的全生命周期管理。

根据客户的数据量和网络条件,我们建议:Oracle的备份以周为备份周期,星期一到星期六做数据库累积增量、归档日志、控制文件和CATALOG用户所有对象的备份,星期天做全备份,保留前面一周期和当前周期的备份,每个周期有两份容余。而且由于该应用的Oracle系统版本较新,也可以利用一些最新的Oracle备份技术,将同样的一份备份数据同时保存在不同的存储介质中去,如磁带和硬盘,以保证备份数据的完整性和安全性。对于Oracle系统的数据备份和恢复的性能,可以通过开辟多个Oracle数据备份通道和多重数据迁移的技术得到保障。

对于以上的备份文件,根据管理的要求设定其保存时间,当此类数据过期时,TSM将自动进行清理,无须管理人员参与。备份时可以利用TSM的永远增量备份的功能、多线程的数据迁移提高数据备份的效率,也可以利用TSM独特的磁带分类集中存放技术保证数据存放的合理性,减少磁带的占用,提高数据恢复的效率。如果此类文件较小的话,可以利用TSM独特的磁盘池的功能,先将这些小文件备份到备份服务器的本地硬盘存储池的TSM临时存储池中,待达到一定百分比时,再一次性迁移到带库中。

恢复操作及策略

可以通过本地的TSM Server结合TSM for Databases利用备份数据进行数据恢复。恢复时,TSM可以实现多线程的数据恢复,可以利用TSM独特的磁带分类集中存放技术,减少磁带的就位时间,提高数据恢复的效率。

先用最近一次的全备份恢复+恢复最近一次的增量备份+增量备份到断点的ARCHIVE LOG来恢复(要求数据库在ARCHIVE LOG模式下工作)。这种恢复方式比全部用ARCIVE LOG恢复要快。

如果两份容余的最近一次增量备份都不可用,可以追溯再上次的增量备份来恢复,然后用增量备份到断点的ARCHIVE LOG恢复。

如果最近一次的全备份恢复都不可用上个周期的全备份+上个周期的最后一次增量备份+本周期的最近一次增量备份+增量备份到断点的ARCHIVE LOG来恢复。

如果增量备份都不可用,那么可以用全备份+ARCHIVE LOG来恢复。

4.3.3 DB2数据库的数据备份及恢复策略

在DB2数据库内部集成了TSM的备份模块,数据能够直接备份到TSM备份服务器或者在TSM备份服务器的控制之下通过LAN-Free的方式将数据通过SAN直接备往带库。结合TSM强大的备份数据追踪寻址能力和介质管理功能,制定灵活的备份策略,实现全自动的备份数据的全生命周期管理。

Tivoli Storage Manager 能够无缝的支持DB2数据库的各种备份操作,而不需要增加任何模块。DB2数据库内部集成了TSM的备份模块,使得数据能够直接备往TSM备份服务器或者在TSM备份服务器的控制之下通过LAN-Free的方式将数据通过SAN直接备往带库。

TSM 提供了备份接口供数据库和应用程序使用,而DB2的备份工具集成了使用该接口的模块。TSM能够不仅能够通过备份接口来备份DB2的data file,还能够备份DB2数据库log file。log file 在变为inactive 时就会被移至User Exit应用程序,然后通过设置可以自动被TSM所接受。如下图所示:

图:TSM 通过应用接口备份DB2

DB2数据库备份的自动调度也可以通过多种方式来实现,如通过TSM的调度、通过DB2的定时备份功能以及通过操作系统的定时功能等。TSM和DB2数据库备份的无缝集成使得DB2数据备份更加安全而有效,从而为用户提供更为方便有效的备份服务。

4.3.4 SQL Server数据库的备份

备份操作将在 Tivoli Storage Manager 存储媒体上创建所有或部分 SQL 数据库的副本。TSM for SQL 提供备份和恢复 SQL 数据时必需的逻辑机制和逻辑。 

当备份执行后,TSM for SQL 将保留关于 SQL Server 和数据库的信息。备份完成后这些信息将用于查询和恢复操作。有关数据库文件组和文件的名称和大小的信息作为子对象与数据库数据一起存储。这些子对象被称为元数据。仅当需要有关单个数据库文件组和文件的信息时才需要此“元”子对象。

TSM for SQL 提供除了完全和日志备份以外范围扩大的备份类型,这样当您不想备份整个数据库或由于备份时间或性能需要不允许执行这样的备份时,它将提供更大的灵活性。Data Protection for SQL 提供六种类型的备份:完全数据库备份、差分备份、日志备份、文件备份、组备份和集备份 

4.4 邮件系统的备份与恢复建议

4.4.1 Domino邮件系统备份与恢复

如果采用Domino系统,可以利用IBM Tivoli Storage Manager for Mail实现在线的热备份。

对于5.0.3以上版本的Domino系统,可以利用Domino的Active Log模式,利用Tivoli Data Protection For Mail实现在线的热备份,可以实现Domino系统的数据库文件的全备份和增量备份,也可以实现Active Log的在线热备份。对于5.0.3以下版本的Domino系统,利用Tivoli Data Protection For Mail实现在线的热备份,也可以实现Domino系统的数据库文件的全备份和增量备份。

对于Domino系统的恢复,可以通过本地的TSM Server结合TSM for mail利用备份数据进行数据恢复。

对于5.0.3以上版本的Domino系统,先用最近一次的全备份恢复+恢复最近一次的增量备份+增量备份到断点的ACTIVE LOG来恢复。

对于5.0.3以下版本的Domino系统,用最近一次的全备份恢复+恢复最近一次的增量备份实现恢复。

4.4.2 Exchange 邮件系统的备份与恢复

如果采用Exchange系统,也可以利用IBM Tivoli Storage Manager for Mail实现在线的热备份。包括邮件组和单个邮件的热备份。

对于备份文件,根据管理的要求设定其保存时间,当此类数据过期时,TSM将自动进行清理,无须管理人员参与。备份时可以利用TSM的永远增量备份的功能、多线程的数据迁移提高数据备份的效率,也可以利用TSM独特的磁带分类集中存放技术保证数据存放的合理性,减少磁带的占用,提高数据恢复的效率。如果此类文件较小的话,可以利用TSM独特的磁盘池的功能,先将这些小文件备份到备份服务器的本地硬盘存储池的TSM临时存储池中,待达到一定百分比时,在一次性迁移到带库中。

对于文件系统和裸设备的备份,可以直接利用TSM Client进行备份。

备份通过TSM的定时机制自动完成。

当操作系统或应用出现问题时导致不可用时,需要通过TSM进行数据的恢复,在本方案中,数据的恢复策略可以根据不同的情况而制定:

4.5 SAP系统的数据备份及恢复策略

对于XXX的SAP系统,我们建议采用TSM客户端与TSM for ERP(SAP)相结合的方法来进行SAP数据的在线备份;TSM for ERP是对SAP进行实时在线备份的软件。SAP的系统是一个三层架构的Server-Client的应用,如下图所示:

图:SAP的三层结构

第一层是数据库服务器(Database server):R/3应用的所有数据和Log都存放在此层,目前,R/3系统支持的后台外挂关系型数据库有:Oracle、DB2、Informix、SQL等,国内使用面最广的是基于Oracle或DB2的R/3应用。

第二层是SAP的应用服务器(SAP Application-server),SAP的源程序和客户开发的R/3应用集中在此层,R/3系统通过一个内部的数据管理工具SAPDBA和数据库服务器紧密的关联在一起,执行对数据库服务器的系统管理、存储管理等。

第三层是用户的操作层(Presentation Client),终端用户通过此层进行系统的具体应用。

因此,从完整的系统存储管理来说,对于SAP的应用,在存储管理方面,必须兼顾数据库服务器和SAP的应用服务器两个层次,才能作到SAP应用的在线备份。Tivoli提供了Tivoli Storage Manager For ERP On Oracle/DB2模块,结合Tivoli Storage Manager,可以对SAP的数据库服务器(Oracle或DB2)进行在线的热备份和恢复。在存储区域网(SAN)的环境下,可以实现不依赖网络带宽(LAN-FREE)的数据备份和恢复。

TSM for SAP和 Tivoli Storage Manager 提供可靠的可再生的操作过程使得系统管理员可以有效的管理大量的数据。它使ERP管理员通过一个定制的界面和SAP DBA提供的功能,同时借助TSM的自动数据管理能力来备份和恢复ERP数据库。TSM for ERP是业界领先的SAP数据保护解决方案。 

在XXX ERP系统中,对于生产系统的ERP服务器,需要使用TSM for ERP软件,保证系统在正常运行时可以在线备份。由于备份工作由ERP的控制接口控制,具体备份的策略结合实际情况,采用全量备份和增量备份结合的备份方式进行。

4.6 操作系统的备份与恢复建议

AIX操作系统数据存放在根卷组(rootvg),而用户数据,包括数据库系统文件及数据、其他文件数据等存放在其他的卷组。那么,用户在进行日常数据备份时,可以通过TSM将用户数据所在的卷组进行备份(包括全备份和增量备份);对于根卷组下的操作系统数据,可以使用AIX操作系统本身提供的命令mksysb来备份到磁带中。这样,在进行系统恢复时,如果只是涉及到某一个卷组、数据库或者是文件,操作系统并没有损坏,那么通过TSM即可完成对系统的恢复;如果发生了系统严重故障,必须重建操作系统时,可以先使用通过mksysb备份出来的磁带来启动,恢复操作系统,再使用TSM来恢复其他的卷组以及数据库、关键文件等数据。其他的UNIX操作系统如Solaris和HP-UX也有类似的命令。

对于Windows操作系统,可以利用系统引导盘快速启动操作系统,进入ASR恢复界面,利用TSM Client备份的操作系统的系统对象快速恢复操作系统。

4.6.1 本地TSM服务器系统的恢复

如果TSM Sever建立在HA的环境下(即TSM Server分别安装在HA的双机上,而数据库文件则建立在共享的盘阵上),一旦TSM Server瘫痪,将由Standby TSM Server自动接管。

如果在配置TSM Server中,已经将其后台数据库作了MIRROR配置,则只需将MIRROR的数据库文件直接激活即可。

否则,我们将会利用对TSM数据库所作的本地备份,利用该数据库的恢复功能恢复本地数据库,直接恢复TSM Server。

4.6.2 当本地整个计算机系统的恢复

如果是硬件或网络的故障,必须首先排除硬件或网络的故障。然后,进行操作系统的恢复,在此基础上,利用Tivoli Disaster Recovery Manager,可以来帮助管理人员实现数据恢复计划的建立和实施。包括实现TSM系统和应用系统的自动重建。通过DRM的实时的灾难恢复计划,有效的管理各种在线和离线的存储介质,为应用系统的恢复提供强有力的保障。而无须系统管理人员在大量的磁带中寻找合适的磁带进行应用系统的恢复。并且,灾难恢复计划是一个非常实用的灾难恢复流程顾问工具,通过DRM,不仅可以自动的恢复TSM系统和应用系统的数据,而且,可以帮助用户进行存储管理流程的建立和优化,实现规范化的存储管理。

同时,如果本地恢复比较困难的话,可以利用本地TSM的Backupset功能,进行本地数据的异地恢复工作。TSM的Backupset,可以把备份节点的文件数据和元数据都写入到同一卷磁带上,因此可以脱离开TSM服务器环境而独立进行数据的读取和恢复。

作者: admin

为您推荐

发表评论

返回顶部