Backup Plan for a VM based sharepoint website

Question

This question was migrated from SharePoint Meta Stack Exchange because it can be answered on SharePoint Stack Exchange. Migrated 8 years ago.

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.

Answer 1

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)

• AvePoint DocAve Backup and Restore
• Backup Exec Agent for SharePoint (PDF)
• Commvault Simpana
• DPM (DPM 2010 is in beta, and yes, this isn't technically third-party)
• Idera SharePoint Backup
• Quest Recovery Manager for SharePoint

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.

Answer 2

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?

John