Sharepoint disaster recovery

Question

What are your disaster recovery plans for Windows Sharepoint Services 3.0 ?

Currently we are backuping all databases (1 content, admin, search and config) using sql backup tools, and backuping the front end server via dataprotector.

To test our backups, we use another server farm, restore the content database (following the procedure on technet) and create a new application that uses this database. We just have to redeploy solutions on the newly created sharepoint application.

However, we have to change database access credentials (on sql server) : the user accounts used on production aren't the same as those used on our "test" farm.

At the end, we can restore our content database and access all our sites. Searching doesn't work, but we're investigating.

Is this restore scenario reliable (as in supported by microsoft) ?

Answer 1

You can't really backup / restore both config database and search database:

• restoring config database only work if your new farm have exactly the same server names
• when you restore the search database, the fulltext index is not synchronize. however, this is not a problem as you can just reindex.

As a result, I would say that yes, this a reliable for content. But take care of:

• You may have to redo some configuration (AAM, managed path...).
• This does not include customization, you want to keep a backup of your solution

Answer 2

Reliability is in the eye of the beholder. In this case, if your tests of the restore process is successful, then yes, it is reliable.

Answer 3

A number of my clients run SharePoint (both MOSS and WSS) in virtual environments, SQL Server is also virtualised and backed up both with SQL tools and with Volume Shadow copy.

The advantage of a Virtual Environment is downtime is only as long as it takes your Virtual Server host to boot the images.

If you are not using Virtualisation, then remember to backup transaction logs regularly as this will make it easier to restore to a given point in the day - it also means that your transaction logs dont grow too big!

Answer 4

I prefer to use the stsadm -o backup command 'for catastrophic backup' as it says in the help. This can be scheduled but requires some maintenance of the backup metadata XML file when you start running out of disk space and need to archive older backups. It has the advantage of transferring over timer jobs (usually) and other configuration because as Nico says, restoring the config database won't work for most situations.

To restore, you can use the user interface which is nice and not have to mess around with much else. I think it restores your solutions as well but haven't tested that extensively.