cancel
Showing results for 
Search instead for 
Did you mean: 

Extremely slow GRT restore from tape - BE2010

gdassieu
Level 3

Hello all,

I am having a big performance issue when restoring using GRT from tape. I have an open case with Symantec, but so far no cream.


Basically, I have a 256Gb VMDK.

If I restore the VMDK to the local BE media server's E:\ drive (using VMware redirection), it restores the whole VMDK in less than 2 hours at an average speed of more than 2.2Gb / min.

However, if I restore a small file from inside that same VMDK using GRT (using the same E:\ drive as staging location), it takes 8 hours to finish! As I check the speed, it begins staging the VMDK at 3Gb/min, but this logarithmically decreases to 200Mb/s near the end.

There's clearly a problem with BE here. The same VMDK restored to the same local drive has completely different performance depending on whether we are doing a VMDK restore or a GRT restore!

have attached an excel file comparing speed graphs for VMDK restore and GRT restore jobs for 256Gb and 100Gb VMDKs, both of them showing the issue (I used a "timed screenshot" program to capture status every 15 minutes).

Any help would be appreciated, since Symantec support has not even been able to reproduce the issue at their labs even after three months of exchanges.

Regards,

Gaston

---------- UPDATE 2011/03/19: Problem solved! -------------

After more than 6 months of exchanges, finally Symantec has found a solution for this problem. First, I upgraded to BE2010 R2 SP1, which reduced GRT restore time in the above case from 8h to 3h30m. Then, they recommended me to apply the below registry keys:

1. Go to "HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\VMware Agent"

2. Create a DWORD  “Enable Buffered Writes" and set to “1” (decimal)

3. Create a DWORD "Number of Write Buffers" and set to “4” (decimal)

4. Create a DWORD “Size of Write Buffers" and set to “512" (decimal)

The above registry keys took download time down to 1h45 minutes, pretty much the same time it takes to restore the VMDK to the local E: drive of the media server.

4 REPLIES 4

gdassieu
Level 3
It would seem this issue is also present in previous BE versions. This post describes the same problem in BE 12.5: https://www-secure.symantec.com/connect/forums/very-slow-restore-backup-exec-125-tape

lgentile
Not applicable
Have you ever gotten this resolved?

We have GRT enabled for some file servers because the file-level backup performance is terribly slow (10mb/sec).  I do not believe it is recommended to use GRT for file servers, but it does seem to 'work'.  However, restoring the VMDK file takes a very, very long time.  We have large volumes (2 TB) that take many days to restore, especially if you just need 1 file or folder.  I realize this is a terrible situation, but it would take over a week for a file server to back up using the standard method.  Our AVVI backups only take a few hours for each file server - so we decided it was better to have some backups than none at all.  I do have an open ticket on both issues (slow backups and slow GRT restores) but we have not had any luck finding a solution.  Our AVVI backups run very fast so it's not a SAN/fiberchannel problem (backups run at 120mb/s or over 7GB/min in most cases) - LTO5 dual drive library system.

Thanks - please let me know if you have gotten any updates..

gdassieu
Level 3
Hello lgentile,

No updates, still working with Symantec support. However, please note that in my case I have no performance issue with backups (whether AVVI or traditional). I only experience a big performance issue when restoring using GRT.

BTW, since my file server is also quite big (1.5Tb), instead of having a 1.5Tb VMDK (which would take ages to stage for GRT restore, and also would require the same amount of available space in the BE media server), I have splitted it into many 256Gb VMDKs. If it wasn't for the big GRT restore performance issue which I am still struggling to solve, I would be able to restore any file using GRT in around 2 hours (that's about the time it should normally take to stage a 256Gb VMDK), which is acceptable for my business.

Kind regards,

Gaston

gdassieu
Level 3

Hello lgentile,

Please also notice that Symatec seems to be working in implementing GRT restores without staging (=directly from tape). That would be top cream.

Feel free to add your comments/encoureagements in this post:
https://www-secure.symantec.com/connect/idea/grt-restores-directly-tape-without-staging-full-vmdk-disk-first

Regards,

Gaston