Navigating SharePoint Server Backup
I think one of the most common IT questions is around how to backup SharePoint Server and when to use SQL backup over STSADM backup. I've chosen 200GB below, but essentially anywhere between 200-500GB or as soon as you're ready to manage it outside of a scheduled task. Let me quickly demistify this for you. There's essentially 5 sets of configuration and data you should be concerned about.
- Content Databases - this is where you data is stored
- Configuration Databases and Admin and SSP Admin Databases - farm and web app configuration including server names, solutions and features you've deployed
- SSP, Search Databases and the Index(es) catalogs - Essentially everything from Profiles, BDC, Search, best bets, properties, content sources
- Server Configuration - IIS configuration including metabase information and other server configuration such as system state including registry
- On disk files - anything in the 12 hive or program files directories you've added or customized, all deployment packages and features (have special copies of these for redeployment), back these up. I'd STRONGLY recommend that there never be anything on disk that isn't in a feature or solution deployment pack, but I realize there are some exceptions that must be documented in your recovery plan especially around search configuration or some changes to specific web.config files. This also includes deployment of any add-ons. Make sure you have copies of these web part packages, interop solutions, search add-ons or whatever they are. I'd say all disks on all servers for simplicity, but this oversimplification doesn't help for more complex environments. If you can do a windiff (file comparison) against a clean box, you'll essentially reveal what the is necessary here. I recommend creating a special directory with a copy of all of the things you deploy to your farm from ifilters, web parts, solutions, web config change history, AAM configuration, the setup files, QFEs, service packs, really keeping a change log that's easy to re apply is essential and this needs to be easy to recover. You may want to keep this in a handy directory or share as a "version" of what you're running from top to bottom. I'd keep this on a staging server or some server off your production environment so you don't have to go to tape if you simply lost a web front end for example.
To backup 1-3 for small environments under 200 GB, you could essentially use the out of the box stsadm -o backup -directory commands to backup the relevant databases. This will need to be scheduled, if you're electing to use Microsoft tools, you'll likely start with a daily scheduled task that should be monitored. I do emphasize monitoring it, there are a number of ways this task can fail with improper perms, failed access to a share, missing flags, already running backup job that hung, etc... You may elect to purchase DPM 2007 or a third party to make the backup easy to do while making retrieval easier and potentially more reliable than a simple scheduled task. Using the -o backup -directory would give you the granularity of content databases. You'd then use NTBackup or whatever normal server backup you use to backup all of the backup files to tape, disk or into your offbox/offsite recovery solution. At this size for 4-5 you can backup all your directories and system state. It's the easiest route to go and you'll be glad you did when you try to locate that ifilter you purchased. (Essentially get a clean copy of 1-5 out of the data center.)
For over 200 GB I recommend no longer using STSAdm to backup the content databases. What's essentially happening in STSAdm -o backup -directory is a SQL backup anyway ;). So as you get more data, you need to have more granularity around it so you can more quickly monitor the jobs for backup up the individual content databases in a quick and manageable way. Use SQL Server to backup 1-2, and if you need granular recovery use DPM 2007 or AvePoint or your favorite backup vendor that supports SharePoint Server 2007 (some backup vendors add special sauce to do brick backups, some do not, so be sure to ask all your questions around ability to get granular recovery and speed) to backup the content for quicker recovery. Some vendors focus on speed, like Quest's SQL litespeed with database backup compression like you'll get in SQL 2008. You should still use stsadm -o backup to backup 3, you essentially want to keep the time stamp as close to the same time for all of the search/index related components (configuration and data). Of all of what you backup, the search, ssp, and index will be the most tricky to get right. I highly recommend you test out your recovery plan on a recurring basis. The ops team must know you to get this right unless your plan is to recrawl.
The larger your databases get, the more creative you'll get. Backup takes a lot of disk IO and network throughput, don't dismiss it as a bottleneck while it's running. It can easily be overlooked as the most heavy usage your boxes may see. This is one reason you may consider a snapshot solution like DPM 2007 or using VLANs to move the Network IO off the NICs that is normally used by your user traffic. Once this isn't competiting for resources with your users you can start to multi thread the processes and backup multiple databases at once. That's one reason I recommend not putting all your data in one large database. I can see I'm moving from simple, but you get the idea.
TechNet has some good resouces on backup "Administering backup and recovery for SharePoint Server 2007". This page was updated January 24, 2008 with more recent information on backup tools and resources including a demo.
If you find yourself frequently recovering databases to restore site collections or sites, I highly recommend the site delete capture tool. It's a simple add on currently posted on codeplex that is used by MS IT and was created using the object model and is deployed as a feature. The source is available if you want to change what it's doing.
