cancel
Showing results for 
Search instead for 
Did you mean: 

Very slow Exchange GRT backups

lu
Level 6
Hi ! We have NBU 6.5.4 and try to run GRT backups on a W2003 SP2 R2 server, with all needed nfs patches. We can see two phases in the backup 1- very fast backup of the store via SAN client 2- very slow indexation when the NFS client/server is involved. It takes 1 to 4 hours to index the 60GB store which contains 5 mailboxes. The exchange server and the media server are connected to the same switch. If we snoop the dialog on the media server, we can see that NFS packets are sent very slowly (about 4-8 KB/s). We see that the NBU nfs server waits 1 second before sending the data (see snoop below). We also found this 1 second delay in the bpdm log (see below). Happens with basic disk and advanced disk. Any idea how to solve this problem ? TIA, Ludo. ------- nfs snoop --------- 2.24509 exchserv -> nbumedia026 NFS C READ3 FH=2283 at 1175568384 for 4096 ==> read request from the Exchange server 2.29524 nbumedia026 -> exchserv TCP D=18624 S=7394 Ack=4153401168 Seq=45132715 Len=0 Win=64240 ==> small ack sent by the media server (len=0) 3.28856 nbumedia026 -> exchserv NFS R READ3 OK (4096 bytes) ==> but data is sent 1 second after the request ! 3.28862 nbumedia026 -> exchserv TCP D=18624 S=7394 Ack=4153401168 Seq=45134175 Len=1460 Win=64240 3.28866 nbumedia026 -> exchserv TCP D=18624 S=7394 Push Ack=4153401168 Seq=45135635 Len=1308 Win=64240 ------- bpdm -------- 14:18:52.572 [13851] <2> read_data: waited for empty buffer 3 times, delayed 71 times 14:18:52.572 [13851] <2> set_restore_cntl: dmcommon.c.6963: firstblk = 0, blocks_to_skip = 0, bytes _to_skip = 0, fragnum = 0 (input parameters) 14:18:52.572 [13851] <2> read_backup: seeking to image relative block number 130967312 frag relativ e block number 130967312 to start read-blockmap ===> here is another 1 second delay 14:18:53.557 [13852] <2> send_bptm_req: [13851] bptm parent answered 0, 0, 0 14:18:53.557 [13852] <2> write_blocks: [13851] writing 2048 data blocks of 512 14:18:53.648 [13852] <2> filter_image_ifr: [13851] sending bp*m position request, curr_frag = 1, ne w_frag = 1, curr_blknum = 130969360, new_blknum = 130967216, firstblk = 130967216 14:18:53.651 [13851] <2> check_positioning: CINDEX 0 wants to skip to frag 1, firstblk 130967216, A CTIVE_GC = 1
41 REPLIES 41

Roger_C
Level 4
Employee
Lu, we tried this on (7.0GA) backing up (using GRT) both Stores in parallel using multiple data streams. Both jobs ended with a Status 0. If you are encountering this issue I would suggest you create a Support case into Symantec Support.
Inform me of the case id and I will get this looked into,

Rog C

MattS
Level 6
Roger,

Though Lu's issue and mine are different we have been using the same EEBs.  Would you be able to test this with 2 mail stores over 100GB, multi-streaming?

My issue is that im getting status 1s for large databases.  The latest EEB solved the issue for me when only allowing one mail store to backup at a time.  Once i allowed multi-streaming it failed with a status 1 again.

The reason i ask to test is that i have not been able to perform another test in our production environment for a couple weeks and im not sure when ill be able to get another test in.

Thanks ahead of time if you are able to help.

Matt