Slow SharePoint restores

[JackG]

Hello,

I'm trying to formulate a disaster recovery plan for our SharePoint environment. So far the solution I have works, but the restores are extremely slow (150-200MB/min).

Here's my setup:

• SharePoint WSS 3.0 installed on a W2K3 VM
• SQL 2008 SP2 installed on a physical W2K3 box
• BackupExec 2010 R3 with SharePoint agent installed on physical 2008R2 box

And this is my DR plan:

1. Recover VM using VRangerPro
2. Install new SQL instance onto an existing Server (different to the live one when we're at our DR site)
3. Create SharePoint and BackupExec SQL logins
4. Restore Web Applications with the SQL redirected to the new SQL instance using the SharePoint Redirection options
5. Restore Config DB - again redirected to new SQL instance

Now, this process does work, however step 4 takes forever! I have about 10 Content DBs in 1 web application - in total about 115GB. Backup Exec will restore the DBs back to the new SQL server with a Job Rate of 3GB/min but as soon as the byte count hits the expected size for that DB the job just seems to hang. Looking on the SQL Server the DB is in a '(Restoring)' state. If I leave it alone for longer enough the job eventually completes and the DB is restored, but I don't know what it is doing or trying to do for the majority of the job! The eventual Job Rate ends up at 200MB/min, meaning my 115GB restore takes around 10hrs to complete - not great.

I've tried many different options but nothing seems to make a difference.

Has anyone had a similar experience to this? if so I'd greatly appreciate your assistance.

Thanks

Jack

[Jaydeep_S]

What is the log file size for the content database. If this is large, it might take longer time to perfrom a recovery and get the Database connected and online.

As a test, try to backup a similir size / configuration database from a SQL server and redirect restore on the DR SQL instance and compare the results.

[JackG]

I set the logs pretty big as I've found that they fill up quickly when users are moving files around in their sites. Having said that though I do a log backup everyday which should truncate them should it not?

We do normal SQL restores during DR, one of which is redirected and this has no problems and is a lot bigger than my SharePoint DBs

[Jaydeep_S]

I would say, a standard Full and Incremental backup strategy should be good to keep consistent backups and also logs under control.

However, as the effective logs size during the restore would large it might take some time to finish. During the restore phase, there would be a SQL log recovery once the database and logs have bee coppied over to the target location.

[JackG]

I'll have a look to see if I can trim the log file sizes down and try it again to see if it makes a difference, although this will take a few days to sort out.

thanks