SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I developed a doc sharing website for my company using Sharepoint2010 and SQLServer 2008 R2.

The website is on a virtual machine powered by Hyper-V

Now, I am thinking the disaster recovery plan.

The options I came up so far are:

  1. Back up the virtual machine
  2. Use CA or Stsadm backup the farm, and use sql utility to back up actual sharepoint databases

Thanks in advance.

share|improve this question

migrated from Nov 16 '11 at 0:55

This question came from our discussion, support, and feature requests site for SharePoint enthusiasts.

up vote 2 down vote accepted

Before you explore options, you should consider your goals. I say this because each option provides a different level of coverage.

  • You have one server now, but what happens a year or two down the road and you add servers into the farm? How will you back these servers up (or will you even need to)?
  • What are your service level agreements (SLA) with the business? Is this SharePoint instance critical to the business? What will happen if there is a significant outage while you are restoring from backups? I gather your particular instance is not super critical as it is contained on a single server, but will you lose your job if the site's not available for a day?
  • How big is your site, and where can you back up all that data?

That all said, there are more or less four high-level options and you could implement one or more of these for added protection:

Back up the virtual machine

This strategy typically involves backing up the Hyper-V VHD(s) as part of a backup that occurs on the VM host. The main benefit to backing up your VM is you can restore the entire server quickly. However, since you are backing up the entire server you typically don't have the ability to perform a restore of anything other than the entire server. Web application corrupted? Gotta restore the whole server. Overwrote a site collection? Restore the whole server. Deleted an item and it's no longer in the recyle bin? Yup, restore the server and lose 30 days or so of content. Alternatively you could restore an old backup elsewhere, spin it up and copy out the content you need. This could be a very intensive operation.

Pros: complete server, simple restore, less troubleshooting following restore. Cons: Must restore entire server, can't restore individual items

Built-in tools

The backup and restore tools in SP2010 have improved since v3. It's easy to restore individual service applications, web applications or content databases. You can automate daily backups with PowerShell and scheduled tasks, and use Central Admin for restores. You still can't get item-level restores, though most of the time the Recycle Bins will come through for you. Also, this backup goes to a network share. Will you have a place where you can have multiple days of backups? For more information, see Back up a farm (SharePoint Foundation 2010). Since it's out of the box, the built-in backup tools are supported by Microsoft and well understood within the SharePoint community. Generally a backup routine using the built-in tools feels kludgy and is not suitable for an enterprise (though that doesn't stop them), especially for compliance.

Pros: Work well, supported by Microsoft and the community, free. Cons: not an enterprise solution, no item-level restore.

Third-party tools

Most backup vendors can backup up SharePoint either natively or with the use of an agent or extension. These tools can be more complicated and significantly more costly, but almost all of them provide the full range of restores from the entire server right down to an item level restore. The restores can be redirected to other farms or disk and generally provide many more features. Again, costly. Third party tools can make use of different backup media and retention policies which are important if your organization has compliancy requirements. Costly.

Here are some tools (I'm not recommending, just listing so you get an idea of what's available)

Pros: Generally a full backup solution that is part of your enterprise backup solution, item-level restore, useful functionality, can satisfy compliance requirements. Cons: Can cost more than your farm, can be difficult to use or support.

SQL Backups

If all you care about are the content databases and you're prepared to attach them to a new farm as needed, this could work for you but generally you'd only do this as a backup to your backup. With a content database you can restore the site collections in the content databases, though with a full recovery model you can restore to a point in time.

Pros: Your DBAs will love them. Cons: Not useful for full farm restores.

share|improve this answer

Ok, so I'm afraid I've got to respond with some questions to better understand what you're doing:

  • Is the farm's SQL Server database instance also on that VM?
  • When you say "Back up the virtual machine", how are you going to do that back up?
  • How many users will the farm have? Do you have any planned maintenance windows for this farm?


share|improve this answer
1. yes, the SQL Server database instance is on the VM. 2. by expoting the VM and saving a copy. 3. I have about 10 users. – Aaroninau Nov 16 '11 at 3:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.