Backup Exec 12在使用Recovery Storage Group进行恢复遇到的问题
2010-11-05 18:16
671 查看
Symantec Backup Exec 12运用了先进的GRT技术,可以对Exchange中的单个邮箱进行恢复,但是在12.0的版本中GRT(Granular Recovery Technology)技术还有一些问题,在恢复Exchange单个邮箱,特别是重定向到某个邮箱时经常会报错,只能恢复部分内容。唯一的解决办法就是升级到Backup Exec12.5,然后再安装补丁就可以了。backup Exec 12.是无法修复这个bug的。
但是我们可以使用Backup Exec 12结合微软的Recovery Storage Group来进行恢复,然后再针对单个邮箱进行恢复。
下面是恢复的过程和遇到的问题。
1.、针对数据库进行备份,这里就不在介绍了。
2、在Exchange System Manager中选中这台服务器,建立一个Recovery Storage Group,然后建立一个恢复的数据库,选择恢复想要的数据库,具体建立的步骤请参照《使用Recover Storage Group对Exchange2003数据库进行恢复》
3.、使用Backup Exec 12对这个数据库进行恢复,但是此时BE12会报错,显示
“Restore- \\*******\Microsoft Information Store\manager
Unable to restore the selected Microsoft Exchange database 'manager-1' because it is currently mounted. Use the Exchange System Manager to dismount it, and then retry the job.”
报错代码:V-79-57344-34041
但是Exchange的Recovery Storage Group的目的就是让源Database在在线的状态下,而将数据透明的回复到Recovery Storage Group中,然后再恢复到生产数据库中,如果dismount源数据库,那就失去了RSG的意义。
这是因为BE在恢复时回去AD里面查看数据库的mount情况,而Exchaneg中这个数据库确实是处于mount状态的。
我们所要做的就是修改一个注册表的键值,让BE忽略mount状态的检查,这样就可以恢复Recovery Storage Group了。具体修改的键值为(在BE 服务器上和Exchange服务器上都要增加):
HKLM\Software\Symantec\Backup Exec For Windows\Backup Exec\Engine\ESE
键名:ingore mount state
类型:Dword
键值:1
这样就可以将数据恢复到Recovery Storage Group了。
英文参考:
Backup Exec (10.1 at least) has an annoying (and undocumented) bug when it comes to restoring to an Exchange 2003 Recovery Storage Group. When you go to restore a mail store to a recovery storage group, BE goes along for a couple minutes and then fails with error "V-79-57344-65280 - Unable to restore the selected Microsoft Exchange database 'MailStoreNameHere' because it is currently mounted. Use the Exchange System Manager to dismount it, and then retry the job.". The whole point of the recovery storage group is to restore user data without dismounting the production store, so this doesn't make a whole lot of sense. Recovery Storage Groups are a feature that is transparent to the backup/restore program. Exchange automatically redirects the restore to the recovery storage group as part of the existing APIs.
Apparently the issue is that Backup Exec is doing a query to Active Directory to determine whether the store is mounted, and of course it is. There is a registry key which can be set to tell Backup Exec to ignore the results of this query. To make this change create the following registry value (DWORD) on the Backup Exec server and the Exchange server:
HKLM\Software\Veritas\BackupExec\Engine\ese
name = "ignore mount state"
value = DWORD(1)本文出自 “chenzhonghua” 博客,请务必保留此出处http://chenzhonghua.blog.51cto.com/128732/415994
但是我们可以使用Backup Exec 12结合微软的Recovery Storage Group来进行恢复,然后再针对单个邮箱进行恢复。
下面是恢复的过程和遇到的问题。
1.、针对数据库进行备份,这里就不在介绍了。
2、在Exchange System Manager中选中这台服务器,建立一个Recovery Storage Group,然后建立一个恢复的数据库,选择恢复想要的数据库,具体建立的步骤请参照《使用Recover Storage Group对Exchange2003数据库进行恢复》
3.、使用Backup Exec 12对这个数据库进行恢复,但是此时BE12会报错,显示
“Restore- \\*******\Microsoft Information Store\manager
Unable to restore the selected Microsoft Exchange database 'manager-1' because it is currently mounted. Use the Exchange System Manager to dismount it, and then retry the job.”
报错代码:V-79-57344-34041
但是Exchange的Recovery Storage Group的目的就是让源Database在在线的状态下,而将数据透明的回复到Recovery Storage Group中,然后再恢复到生产数据库中,如果dismount源数据库,那就失去了RSG的意义。
这是因为BE在恢复时回去AD里面查看数据库的mount情况,而Exchaneg中这个数据库确实是处于mount状态的。
我们所要做的就是修改一个注册表的键值,让BE忽略mount状态的检查,这样就可以恢复Recovery Storage Group了。具体修改的键值为(在BE 服务器上和Exchange服务器上都要增加):
HKLM\Software\Symantec\Backup Exec For Windows\Backup Exec\Engine\ESE
键名:ingore mount state
类型:Dword
键值:1
这样就可以将数据恢复到Recovery Storage Group了。
英文参考:
Backup Exec (10.1 at least) has an annoying (and undocumented) bug when it comes to restoring to an Exchange 2003 Recovery Storage Group. When you go to restore a mail store to a recovery storage group, BE goes along for a couple minutes and then fails with error "V-79-57344-65280 - Unable to restore the selected Microsoft Exchange database 'MailStoreNameHere' because it is currently mounted. Use the Exchange System Manager to dismount it, and then retry the job.". The whole point of the recovery storage group is to restore user data without dismounting the production store, so this doesn't make a whole lot of sense. Recovery Storage Groups are a feature that is transparent to the backup/restore program. Exchange automatically redirects the restore to the recovery storage group as part of the existing APIs.
Apparently the issue is that Backup Exec is doing a query to Active Directory to determine whether the store is mounted, and of course it is. There is a registry key which can be set to tell Backup Exec to ignore the results of this query. To make this change create the following registry value (DWORD) on the Backup Exec server and the Exchange server:
HKLM\Software\Veritas\BackupExec\Engine\ese
name = "ignore mount state"
value = DWORD(1)本文出自 “chenzhonghua” 博客,请务必保留此出处http://chenzhonghua.blog.51cto.com/128732/415994
相关文章推荐
- 使用Recover Storage Group对Exchange2003数据库进行恢复
- 使用RadioGroup+ViewPager+Fragment实现带滑动的页卡效果TabHost时遇到的问题
- 使用phonegap进行移动跨平台在Android平台开发所遇到的问题
- 使用Mencoder进行视频转换遇到的问题和相关解决方案
- 问题12:如何利用oracle bbed 来模拟破坏数据块,并且用RMAN进行恢复?
- linux中使用jmeter进行压力测试执行篇及遇到的问题
- 在使用putty工具进行远程登录时也许会遇到一些问题,下面列出了一些问题有利于帮助大家解决:
- [python] 2、python使用pyaudio进行录音,及其在python虚拟环境virtualenv中安装遇到的问题
- 使用Pycharm 社区版配合anaconda进行代码编写遇到的一些小问题汇总
- iOS开发中使用SCRecorder进行视频裁剪遇到的问题
- 小存储嵌入式设备上使用thttpd进行文件上传遇到的问题
- Chrome 下,重复使用 XMLHttpRequest进行Post数据时,遇到一个奇怪的问题
- MyBatis使用foreach进行批量插入遇到的问题以及解决方法
- 使用SVN进行版本控制时遇到的一些问题
- IDEA下单独使用MybatisJDBC进行持久化遇到的问题分享。
- 在spring中使用quartz进行任务调度遇到的问题
- android使用CMake进行jni编写遇到的一些问题
- .net中使用TripleDESCryptoServiceProvider进行3DES加密遇到弱密钥的问题
- 使用github和SourceTree进行源代码管理遇到POST git-receive-pack (chunked) 问题
- 使用Linq查询数据进行分页时遇到的性能问题