veritas netbackup恢复步骤

前段时间,做了一次nbu的同机恢复测试。
环境是这样的:
备份和还原都是在一个机器上,hostname是sg2as059。即备份的client是这个机器。数据库的实例名是test.
无catalog数据库,备份信息保留在控制文件中。
备份的master server和media server是同一台机器,hostname是sg2ts001。

前一天晚上设置nbu的policy进行备份,备份脚本在client上:

从备份脚本得知,备份的log是同目录下的,和备份脚本同名的.out文件。
因此我们可以检查一下备份的log,看看是否备份成功,以及获取其他还原时需要的信息:

在这里面有大量一会我们还原数据库时所需要用到的信息,因此该log非常重要,建议也备份到磁带上。

另外,我们也可以通过bplist来看备份集:

sg2as059:/usr/openv/netbackup/ext/db_ext/oracle/test>/usr/openv/netbackup/bin/bplist -t 4 -l -R /

下面我们开始设计一些场景来进行数据库的还原:

场景一:丢失spfile:
如果我们丢失了spfile,我们可以以下方式还原:
1. 用rman连接数据库,注意由于没有spfile,数据库无法启动,需要现在rman下启动一个dummy数据库。另外,由于数据库还未启动都mount状态,因此无法用rman sys/change_on_install@tnsname的方式连接数据库。只能用os鉴权的方式登录。

2.因为要恢复spfile,我要set dbid,由于没有用catalog,我们无法list incarnation,我们只能从备份的log去找dbid,注意log中的以下信息:

因此我们获得dbid是2051517555。

3.restore spfile,注意我们由于是同机恢复,因此写与不写环境变量都没关系;如果是异机恢复,就必须在rman中写上环境变量。在这个例子中,我们写上环境变量来进行恢复。
另外这里注意需要指明是从那个backupset中恢复。我们需要去查备份的log,确定spfile的备份是在哪个备份集中:

因此,利用上述信息进行spfile的还原:

注,关于上述的client和server的信息,可以根据bp.conf 文件来确定:

在此过程中,可以在nbu的控制台看是否已经restore操作。
也可以另开窗口,看到该rman的等待事件是sbtrestore。
另外,也可以看nbu的log,如果没有新log产生,说明备份还停留在rman部分,没传递给NBU。

还原spfile后,关闭原来的dummy数据库,正常启动数据库。

场景二:丢失控制文件。
丢失控制文件的场景和丢失spfile类似,而且步骤根据简单一些,不需要启动dummy数据库,根据log选择控制文件。

数据库需要启动到nomount状态:

还原控制文件之后,resetlogs启动数据库。

场景三:丢失数据文件

场景四:丢失redo log.
由于redolog不在rman备份范围之内,因此在做恢复的过程不需要nbu的参与,只是常规恢复。
如果丢失的redolog不含active或者current的redo,用recover database until cancel+resetlogs打开;
如果丢失的是active或者current的redo,就需要用_allow_resetlogs_corruption的隐含参数+resetlogs打开。
这里不展开叙述。

场景五:丢失全部文件(控制文件数据文件和日志文件)。
注意会自动restore arch,需要留心arch目录的大小。

【Trouble shooting】
一、恢复时,如果用parms来传递环境变量时会报错sbtinfo2,解决方法是用send,而不是parms:

二、恢复spfile时,如果用from autobackup,会挂死,NBU找磁带会非常慢。该rman的等待事件是sbtinfo2。解决方法是指明from某个备份集文件,这就要到备份的log中去找了。

此时去看等待事件:

相关文章

3条评论

  1. 总结得真好,思路清晰,解释到位,最近刚好也做了个类似的恢复测试,要是早点看到这篇文章就好了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据