Still trying to resolve - Slow Exchange 2007 restore while staging from tape

[Noah_Adams]

I'm still trying to resolve the issue that I posted about here - https://www-secure.symantec.com/connect/forums/exchange-grt-restores-tape-run-150mbmin

I'm currently running a restore of a mailbox, and the staging process is running at 150MB/min. All other restores using the same source and destination hardware run at ~800MB/min. Can anyone help me figure out why the Exchange staging process is so slow?

[ZeRoC00L]

Do you still have BE2010 R2 installed, or already upgraded to R3 ?
If you did not upgrade, I suggest to upgrade to the latested version, and install all available patches.

[CraigV · Accepted solution]

...are you staging locally?

try staging manually yourself as per my document below and see if it makes any sort of difference:

https://www-secure.symantec.com/connect/articles/restoring-exchange-or-individual-mailboxesitems-using-backup-exec-howto

Also, check and see if your AV is scanning your BE services, and if so, put in an exclusion for the services and try again...

[Noah_Adams]

ZeRoC00L - We are still running R2, but this issue has existed since we moved to Exchange on 12.5. I can update the server after today's backups are done.

CraigV - We currently run our Exchange backups to disk, and then to tape. For the 5 days that I have B2D data, restores are not a problem. I read through your guide, but it looks like it only addresses restoring data that currently exists on the server. I'm trying to restore data from a tape that's from April of 2011.

The staging area is currently set to the "E:" drive on our backupserver, so the data is coming from a directly-attached tape drive to a directly-attached array.

[CraigV]

...how is your job configured? Backup-to-disk then duplicate to tape? You don't back up the *.bkf files directly? I've read on the forums that if you do so it messes up the catalogs/information and can make things problematic when trying to restore.

[Noah_Adams]

I have a Backup to Disk job that's configured for GRT running to a NAS. I then have a duplicate job (set up using the BE "Duplicate Job" feature) that offloads it to tape. As far as I'm aware, I have everything configured the way BE is intended to be set up.

Last night my test restore ran for 15 hours and only staged 120gb of the 330 total. At this point, my disaster recovery timeline is unattainable simply because I'd be tying up the tape drive for over a day just to restore Exchange.

[CraigV]

...doesn't matter if you're restoring from last month, or a year ago...you're still able to manually stage to disk if need be. Unless you have the actual Information Store sitting on your tape (and reading what you described above on how you configured your jobs you should have that), you could still try manually staging.

If you have *.bkf files instead, I think you have to duplicate to disk first, reinventory and catalog them and then try the restore.

[Noah_Adams]

Craig,

I have to apologize... I didn't read your guide accurately, and thought it was just duplicating the previous night's backup. I created a new B2D folder on the backup server's secondary array and attempted a duplicate off the tape. The result was the same - 150mb/min.

So, I created a new B2D folder on a network share of a different machine, and am currently running the duplicate to that, at 1,500mb/min. It seems that I have some sort of configuration issue with the secondary array on the backup server. It's configured with (4) 300gb 10k SCSI drives in RAID 5.

[CraigV]

...check the fragmentation on that drive...to get a faster speed across a LAN means there is something misconfigured/failed or failing/performance limiting on that server.

[Noah_Adams]

Ultimately, we will be using your pre-staging solution to stage it to a different server.

What I found out is that the local array on the backupserver doesn't have any write cache available, which is leading to poor write performance. Rather than upgrade the 5 year old server, we'll just stage it elsewhere.

Thanks for your help!