12-01-2013 10:55 PM
I have MS Exchange 2010 standalone installation in VMware 5.1 virtual infrastructure. Also I have NBU 7.6 FA master standalone server in virtual machine too.
All configs I done according to the documentation "Symantec NetBackup for Microsoft Exchange Server Administrator’s Guide for Windows Release 7.6". All versions - master server and client - is the same. OS version on client side is MS 2008 R2.
I try to backup with VMware Policy and GRT restore individual messages with MS-Exchange Policy. Backup process looks fine:
01.12.2013 21:10:48 - Info nbjm (pid=3612) starting backup job (jobid=194) for client exchange.mydomain.ru, policy exchange.mydomain.ru, schedule Full
01.12.2013 21:10:48 - estimated 1817082459 kbytes needed
01.12.2013 21:10:48 - Info nbjm (pid=3612) started backup (backupid=exchange.mydomain.ru_1385910648) job for client exchange.mydomain.ru, policy exchange.mydomain.ru, schedule Full on storage unit pd_unit
01.12.2013 21:10:48 - started process bpbrm (pid=5596)
01.12.2013 21:10:49 - Info bpbrm (pid=5596) exchange.mydomain.ru is the host to backup data from
01.12.2013 21:10:49 - Info bpbrm (pid=5596) reading file list for client
01.12.2013 21:10:49 - Info bpbrm (pid=5596) accelerator enabled
01.12.2013 21:10:51 - Info bpbrm (pid=5596) starting bpbkar32 on client
01.12.2013 21:10:51 - connecting
01.12.2013 21:10:51 - connected; connect time: 0:00:00
01.12.2013 21:10:53 - Info bpbkar32 (pid=2036) Backup started
01.12.2013 21:10:53 - Info bpbkar32 (pid=2036) accelerator enabled backup, archive bit processing:<disabled>
01.12.2013 21:10:53 - Info bptm (pid=2324) start
01.12.2013 21:10:53 - Info bptm (pid=2324) using 262144 data buffer size
01.12.2013 21:10:53 - Info bptm (pid=2324) setting receive network buffer to 1049600 bytes
01.12.2013 21:10:53 - Info bptm (pid=2324) using 30 data buffers
01.12.2013 21:10:54 - Info bptm (pid=2324) start backup
01.12.2013 21:10:54 - begin writing
01.12.2013 21:12:59 - Info bpbkar32 (pid=2036) INF - Transport Type = hotadd
01.12.2013 21:30:25 - Info bptm (pid=2324) waited for full buffer 1938 times, delayed 11314 times
01.12.2013 21:30:26 - Info bpbkar32 (pid=2036) accelerator sent 27545917952 bytes out of 1533192415232 bytes to server, optimization 98.2%
01.12.2013 21:30:26 - Info bpbkar32 (pid=2036) bpbkar waited 10850 times for empty buffer, delayed 13733 times.
01.12.2013 21:30:30 - Info bptm (pid=2324) EXITING with status 0 <----------
01.12.2013 21:30:30 - Info nbu-s2.mydomain.ru (pid=2324) StorageServer=PureDisk:nbu-s2.mydomain.ru; Report=PDDO Stats for (nbu-s2.mydomain.ru): scanned: 1497303482 KB, CR sent: 16996502 KB, CR sent over FC: 0 KB, dedup: 98.9%, cache disabled
01.12.2013 21:30:30 - Info bpbrm (pid=5596) validating image for client exchange.mydomain.ru
01.12.2013 21:30:31 - Info bpbkar32 (pid=2036) done. status: 0: the requested operation was successfully completed
01.12.2013 21:30:31 - end writing; write time: 0:19:37
the requested operation was successfully completed (0)
But when I try to restore individual messages from existing mailbox to the same path, I have error:
02.12.2013 12:18:30 - begin Restore
02.12.2013 12:18:31 - restoring from image exchange.mydomain.ru_1385910032
02.12.2013 12:18:31 - Info bprd (pid=1368) Restoring from copy 1 of image created 12/01/13 21:00:32 from policy exchange.mydomain.ru
02.12.2013 12:18:31 - Info bprd (pid=1368) Granular restore has started, this may take a while....
02.12.2013 12:18:34 - Info bpbrm (pid=2324) EXCHANGE is the host to restore to
02.12.2013 12:18:34 - Info bpbrm (pid=2324) reading file list for client
02.12.2013 12:18:35 - connecting
02.12.2013 12:18:35 - Info bpbrm (pid=2324) start nbfsd on client
02.12.2013 12:18:37 - Info bpbrm (pid=2324) start nbgre on client
02.12.2013 12:18:44 - Info tar32 (pid=0) Restore started
02.12.2013 12:18:44 - connected; connect time: 0:00:00
02.12.2013 12:28:18 - Error bpbrm (pid=2324) from client EXCHANGE: ERR - Unable to restore. Skipping file: Microsoft Information Store\DOR_database2\Database\testbackup [testbackup97c]\Top of Information Store\Inbox\RE: ???????? <00000000fb55387cbb3d8340ad5c531f736769a2070095c55a2cfd692643b3815f4e23f784760000004ea413000095c55a2cfd692643b3815f4e23f784760000004ecd900000>
02.12.2013 12:28:19 - Info tar32 (pid=0) done. status 103
02.12.2013 12:28:19 - Info tar32 (pid=0) done. status: 103
02.12.2013 12:28:19 - Info tar32 (pid=0) done. status: 103: error occurred during initialization, check configuration file
02.12.2013 12:28:19 - Error bpbrm (pid=2324) client restore EXIT STATUS 103: error occurred during initialization, check configuration file
02.12.2013 12:28:19 - restored from image exchange.mydomain.ru_1385910032; restore time: 0:09:48
02.12.2013 12:28:19 - end Restore; elapsed time 0:09:49
MS-Exchange policy restore error (2810)
And error in bpbrm.log:
12:28:18.902 [2324.6184] <16> bpbrm main: from client EXCHANGE: ERR - Unable to restore. S
kipping file: Microsoft Information Store\DOR_database2\Database\testbackup [testbackup97c
]\Top of Information Store\Inbox\RE: Oaiuaiea <00000000fb55387cbb3d8340ad5c531f736769a2070
095c55a2cfd692643b3815f4e23f784760000004ea413000095c55a2cfd692643b3815f4e23f784760000004ec
d900000>
12:28:18.918 [2324.6184] <4> db_error_add_to_file: from client EXCHANGE: ERR - Unable to r
estore. Skipping file: Microsoft Information Store\DOR_database2\Database\testbackup [test
backup97c]\Top of Information Store\Inbox\RE: Oaiuaiea <00000000fb55387cbb3d8340ad5c531f73
6769a2070095c55a2cfd692643b3815f4e23f784760000004ea413000095c55a2cfd692643b3815f4e23f78476
0000004ecd900000>
12:28:18.934 [2324.6184] <2> read_client: ?
...
12:28:19.027 [2324.6184] <2> bpbrm write_msg_to_progress_file: (232.001) ERR - Unable to r
estore. Skipping file: Microsoft Information Store\DOR_database2\Database\testbackup [test
backup97c]\Top of Information Store\Inbox\RE: Oaiuaiea <00000000fb55387cbb3d8340ad5c531f73
6769a2070095c55a2cfd692643b3815f4e23f784760000004ea413000095c55a2cfd692643b3815f4e23f78476
0000004ecd900000>
12:28:19.121 [2324.6184] <2> bpbrm write_msg_to_progress_file: (232.001) INF - GRE EXITING
WITH STATUS = 103
12:28:19.121 [2324.6184] <2> bpbrm main: from client EXCHANGE: INF - GRE RESTORED 0 OF 1 S
UCCESSFULLY
12:28:19.136 [2324.6184] <2> job_monitoring_exex: ACK disconnect
12:28:19.136 [2324.6184] <2> job_disconnect: Disconnected
12:28:19.136 [2324.6184] <2> bpbrm write_msg_to_progress_file: (232.001) INF - GRE RESTORE
D 0 OF 1 FILES SUCCESSFULLY
Can anyone to point me what can I do to resolve this problem?
Solved! Go to Solution.
01-22-2014 08:03 AM
That log is verbose enough. Perfect.
Looks like its an issue with the virtfile driver.
I see this in the log:
12-23-2013 09:01 AM
can we have tar log pls seems something wrong in restore configuration . could be incorrect path
12-23-2013 09:21 AM
Do you have the Microsoft Messaging API and Collaboration Data Objects installed on your exchange nodes - as well as the NFS and everything else you need that installed to actually do the restores of individual items
12-23-2013 10:50 AM
mark i guess for ex2010 CDO is not required...
12-23-2013 08:55 PM
Hi Mark, Jack!
At first, we have a problem with GRT restore only from VMware-Policy Exchange server. When we backup Exchange with traditional MS-Exchange-Policy - we can GRT restore without any troubles.
And secondly, sorry I can't to provide TAR logs for the our original problem. Now we have another one. :(
May be problem in big size our exchange database (about 1.5 Tb). Now we can't to view the content of VMware-Policy archives. Some strange error (look to Clipboard01.jpg in attach). But at the same time all looks good with MS-Exchange-Policy archives (look to Clipboard02.jpg in attach).
P.S.: Sorry for my bad english (
12-24-2013 02:33 AM
OK - not exactly going to help with this restore but a few things that may help you here:
1. Increase the client read timeout on your media servers - maybe 3600 to allow plenty of time for the system to mount and read the databases
2. Reduce your fragment size on you storage unit - 5000MB works well for GRT restores / duplications - it helps the system locate the blocks in needs much quicker - it may also prevent the timeout you are getting when doing the browse / restore
3. Set the media server to be the GRT proxy server (exchange servers host properties - windows - exchange) so that all of the work takes place on the media server and not the exchange server
I know you wont be able to test this until you have run a new backup with the new fragment size but hopefully it will help for future restores
There are lots of pre-requisites as well so it is worth just double checking everything in the guide
You can also catalog a GRT exchange backup to make browsing the contents quicker - the bpduplicate -bc option is used for that.
12-24-2013 03:01 AM
12-24-2013 03:05 AM
Apologies - it was the -bc_only switch
The media server should be the same O/S version as the Exchange Server according to the latest docs - whether that just means "Windows" or a lot deeper i am unsure to be honest - you could give it a try anyway - that would work with existing images so easy to test
12-24-2013 03:18 AM
12-24-2013 03:22 AM
AH! - Hitting a 10 minute timeout somewhere (though looks like 9 minutes!) - same as the issue when browsing
If all timeouts have been increased then it may be that the new hardcoded timeouts for bpcd and bpdbm that were increase in 7.5.0.4 (I think) may have crept back into 7.6
Worth double checking all of your client read timeouts - including for the Master Server though
12-24-2013 03:34 AM
> Worth double checking all of your client read timeouts - including for the Master Server though
Hmmm... Look to attach - timeout settings for Master server, Media server (the same host that Master) and Client.
12-24-2013 03:49 AM
OK - could be the old harcoded timeout has crept back in then.
I dont see anything the the 7.6.0.1 notes to say it was fixed from 7.6 FA
May be worth raising a case
12-24-2013 03:59 AM
OK
Will try the last option - with media server host as GRT proxy host in client's settings...
12-24-2013 04:03 AM
There is a section saying that the O/S must be supported - so if the media servers are 2008 you should be fine
12-24-2013 08:55 PM
Unfortunately again, did not help. The same error: status 220 database system error. :(
bpdbm log:
12-27-2013 07:34 PM
Did you had chance to upgrade your environment to 7.6.0.1 (its GA now). As error in last log was resolved in 7506. Wondering its poping up again in 7.6 FA
Get hold of support and check if there is EEB which can be helpful
01-15-2014 03:58 AM
Hello,
Have you resolved this issue? Did you find some solution?
01-15-2014 04:00 AM
Unfortunately we have not found ((
01-16-2014 10:26 PM
01-16-2014 10:33 PM
I have found another symptom in ncflbc log on the exchange server client side.
When I try to browse VMware policy backup, in the logs I I see the following: