I am relatively new to sharepoint 2010 administration, and am coming from a sql server admin background. we currently have a farm with 2 wfe, 1 app, and 2 db servers (clusterered) and about 100 gig total db size and we want to figure out a proper backup/restore strategy. I have read a plethora of docs from microsoft and blogs, and I think I have a small disconnect between the relationship of full farm backups and sql server db backups.. I am under the assumption I should be taking full farm backups regularly as in a dr scenario just taking a sharepoint configuration backup + sql server backups will leave alot to be desired in the restore scenario.. however taking frequent full farm db backups as well as full sql db backups seems like it is quite redundant.. and in the case of a dr scenario and I had to restore the farm, I would end up restoring the farm and then having to restore all the database backups anyway to get to a point in time.. Am I offbase in this assumption?
Is there a scenario that maybe doing only farm backups then a regular snapshot rotation of content database (for unattached restores) makes sense?
I guess I am just asking how other organizations plan out the backups? What kind of retention do you do as far as keeping backups on disk for quick restores.
I would really appreciate any feedback. Thank you in advance!
The full farm backup includes SQL backups, but they are stored in a way that isn't trivial for restoration directly into SQL Server. SQL Server backups will provide you with database backups that as a DBA are more familiar to you. If you're using full recovery on the database you get the point in time restores which the farm backup does not provide.
The farm backup is suited primarily for DR scenarios (in WSS 3.0/MOSS 2007 it was called the "catastrophic backup"). Ideally, should your data centre burn to the ground, you can use your off-site full farm backups to restore the entire farm. You simply spin up some new servers, install SQL Server, install SharePoint, create a farm, join all the servers to the farm, and restore the backup. Basically it restores the content and (most) configuration.
You can also use the full farm backup to restore specific components down to the database level (so no site collection, sites, lists, items, documents). This is useful if someone accidentally deletes the managed metadata service, or changes the user profile synch and imports the 250,000 accounts in the test domain. Simply restore the service from your most recent farm backup and you're back to where you were. Note: since you'll lose any changes between the backup and the event that required you to restore, you may lose data you need.
The SQL Server backups are most useful for content database recovery. As I mentioned before, if you are using the full recovery model, you can restore the content database to a specific point in time, such as the minute before your just layed-off SharePoint admin deleted all your sites. You can also use database backups to move data between farms, say from production to test, or in a migration scenario from 2007 to 2010. You can also backup service databases and restore these as well, there is guidance out there around how to do this.
Generally you have no use for configuration database backups, as you can't directly restore these. SharePoint 2010 now has the Backup-SPConfigurationDatabase that allows you to backup the configuration database.
TechNet has some good documents for backup and recovery, though note that these are mostly applicable with the out of the box SharePoint and SQL tools. If you are using a third-party tool the concepts may be applicable but the proceedures and details may not.
- Backup and recovery overview (SharePoint Server 2010)
- Plan for backup and recovery in SharePoint Server 2010
- Backup and recovery best practices (SharePoint Server 2010)
- Edited by Jason WarrenMVP Wednesday, March 14, 2012 5:30 PM Added some links
Great reply.. thank you very much .. so then I would assume most sites would use a combination of the two .. Full Farm backup (including content db etc) monthly, then differential weekly or something used only in cases of DR (or perhaps a MOCK restore?).. and also have a sql maintenance plan that does full and transaction log backups for being able to restore individual components on a needed basis? Have you heard of more sites leveraging snapshot databases of content databases for ease of unattached restores/speed of backups/size of backups? in lieu of keeping multiple standard backups on disk?
Database snapshots are perfectly fine, there's even an article on TechNet specific to SharePoint: http://technet.microsoft.com/en-us/library/ee748594.aspx. The recommendation there is you would use snapshots in addition to full farm backups.
My experience with most of my customers is they use a third-party tool for SharePoint backups. Usually the tool is the same tool they are using to backup their enterprise and they acquire a SharePoint add-on product (agent, extension, license, etc) or most recently it's a feature of their SAN. This way they can leverage their existing backup infrastructure and investment, backup SharePoint directly to the same backup media as the rest of their organization, and in most cases reap the benefits of item-level restore that most third-party SharePoint backup tools provide (they'd rather spend the money on the tool than the money restoring 100 GB databases, attaching them, and trying to locate a file to restore).
I strongly disagree that the Farm Backup option stores the SQL database backups is such a way that is "non-trival" to restore to SQL Server. I routinely do this. All you need to do is open up spbackup.log, find your database (as named in SQL Management Studio), then find the name SharePoint used to save the file to disk. Take that file and simply restore it into SQL Server.
We typically use the SharePoint Full backup twice a month.
This is mainly because we have a stable environment without a lot of setting change, I would advise more frequent farm backups for a farm that is being implemented or is going through multiple setting changes.
For content databases we do full SQL backups twice a week with differential backups every day and trans backups every half hour.
This is specifically for the content databases so we can recover with a very specific RPO (less content loss the better) and rapid RTO (time to recover data).
When creating a backup and recovery plan pay attention to what can be restored via SharePoint and what can be restored with other tools.
Specifically the entire farm, service applications, and web applications.
SQL backup/restore alone will not give you a fully operational farm.
At the end of the day it is a mix of SharePoint backup/restore and SQL backup/restore.
The rule of thumb I go by is SharePoint backup/restore is good for configuration that doesn't change often and SQL backup/restore for content and data that changes often.
We use this plan on a public website based on WCM with tons of edits hourly with a successful 99.9 SLA.
Like many things, the way you accomplish tasks in SharePoint is based on "It Depends".
If this helps you then please mark the post as helpful. If this answers your question then mark it as the answer. If another contributor in the thread answers your question then please do the right thing.