There were many options for disaster recovery with WSS 3.0 and MOSS 2007. The native tools all had significant advantages, and unfortunately disadvantages. Methods that offered the best protection against full-scale disasters offered little to no granular protection against more common ‘accidental deletion’ moments. STSADM, the SharePoint command-line administration tool, offered the only native way to schedule backups by means of simple batch files – but it was painfully slow and many times marked the site collection read-only as it worked.

Because of these limitations, many organizations either used multiple types of backups to protect against different scenarios, or relied on third-party products to fill the gaps (or even to completely replace the native tools).

With the new SharePoint 2010 functionality, these limitations no longer pose significant obstacles. With enhancements to Central Administration’s backup / restore tools and the addition of Windows PowerShell cmdlets to our command-line tool belt, it is now possible to cover most issues and / or scenarios with a single disaster recovery scheme that protects your SharePoint configuration and data from both granular, accidental deletions and true large-scale disasters.

Big Picture

This post is specifically addressing the backup and recovery of SharePoint configuration and data – not A.D. or other directory providers, your server environment, branding, and programmatic customizations such as features and solutions. The strategy for protecting those elements will vary greatly depending on your organization’s overall disaster recovery strategy which may include traditional tape backup, virtual machine snapshots, server imaging, off-site replication, shared software installation points… At the very least, you should have a copy of all installed solution packages stored and backed up with the rest of your installation media.

Obviously, to offer any kind of protection against large or small scale disasters, backups must occur regularly and automatically. To schedule backups of SharePoint data, an administrator has two options – SQL and PowerShell. SQL does not offer full configuration backup on its own – but PowerShell does.

In fact, SharePoint 2010 adds about 300 new cmdlets that provide a much more flexible, interactive, and granular tool for SharePoint than STSADM ever did. Several of these cmdlets provide the same backup functionality available manually through the Central Admin site, including the ability to pick and choose which farm elements to backup / restore. An administrator can now schedule regular backups of SharePoint content and configuration completely via Windows PowerShell and Scheduled Tasks, and then perform granular restores (down to the individual list level) through the web GUI available in Central Admin if he prefers.

The Nitty Gritty…

Let’s take a look at the Central Admin ‘Backup and Restore’ page to see what is possible here.

1. Login to your SharePoint server, and go to Start > Administrative Tools > SharePoint 4.0 Central Administration.
   
2. Click on the first displayed link, ‘Perform a backup‘, and you’ll see a tree view of all farm elements. Notice that this includes the configuration database, web application setup, content databases, service applications, user profiles… Pretty cool, ehh?
   
   
   
   
   

This same tree-view is shown during a restore, so that on either end of the process the administrator can select all or any part(s) to work on. These component names in the first column can also be shown and referenced in the PowerShell environment by the same names. To open the SharePoint PowerShell environment:

1. Go to Start > Administrative Tools > SharePoint 4.0 Management Console (SMC). (This may take a moment to load, don’t get impatient.) Type the following to display the components hierarchically by name: Backup-spfarm -showtree.
   
   Why do we care? The backup-spfarm cmdlets includes a parameter that allows us to select individual items instead of the entire farm.
2. To see some basic help text on the usage, type:

   backup-spfarm -?. (A complete reference of the –detailed text of all SharePoint PowerShell cmdlets is being built at http://sharepointsolutions.com/sharepoint-help/groups/sharepoint-2010-powershell-reference/home/).
   

3. For this basic backup requirement, we need to create a full backup of the entire farm.
   Type: backup-spfarm –directory \\fileserver\backupshare -backupmethod full.
4. If your datasets are too large to do a full farm-level backup every day, you may wish to do this weekly and then backup only the content nightly. To create a backup of just a content database type the following command in the SMC:
   Backup-spfarm –directory \\fileserver\backupshare -item “name as listed in tree above” –backupmethod full

In the background, these backup commands are using different backup methods to protect different components. For instance, the content is backed up via a remote SQL database backup statement. A complete log of the backup attempt is kept in the ’spbackup.log’ file in the backup directory you specified in the command above. If there are any warnings or errors, the SMC will give a generic message that ‘The backup job failed…’ That doesn’t mean the entire job failed, but you will have to check the log file to find out where the problems were encountered.

Now that you know how to form the basic SharePoint PowerShell commands, the next step is to schedule them. This process is made up of a couple of steps.

1. Configure PowerShell to allow scripts. In the SMC, type:
   set-executionpolicy RemoteSigned
2. Create a PowerShell script (.ps1 file extension) containing a couple of standard lines necessary to load the SharePoint cmdlets and then the command(s) we just tried above. (Below is an example based on backing up just a single content database.)
   

   If you need to clear previous backup directories to conserve disk space, you can do this in your ps1 PowerShell script, as shown here.

3. Here are the steps to use the Task Scheduler functionality in Windows 2008 Server to schedule your script to run on a daily basis. (If you are using Win2k3 as your OS, the steps are similar but they would be done in the older style Scheduled Tasks tool.)
   Go to Start > All Programs > Accessories > System Tools > Task Scheduler, and click on the Create Basic Task… link on the right side.
   
   Type a descriptive name, and click Next.
4. Click the Daily button, and click Next.
   
5. Enter your desired daily start time, and click Next.
   
6. Click the Start a program button, and click Next.
   
7. Type powershell in the Program/script blank, and then -command “& ‘your ps1 file path and name‘ ” in the Add arguments (optional) blank.
   
8. Click Next and Finish.

If you have multiple PowerShell scripts to run (for full & differential, or farm-level & content db’s only), then you would schedule each script separately using this same method. In most organizations, I recommend starting with weekly PowerShell full farm-level backups, and nightly PowerShell backups of content databases. One advantage of scripting these backups via Powershell is the ease of multi-threading. The Backup-SPFarm cmdlets includes a ‘–threads’ parameter, and by putting each content db backup in its own script you can schedule them independently where each one starts with its own thread. That also allows you the flexibility to backup some content databases more frequently than others.

That’s all you require to create useful, inclusive, and granular restore capability for your 2010 SharePoint farm. A big part of the reason this is so powerful though, is on the restore side of the equation. Look for a follow-up post that describes in detail how to use Central Admin and / or PowerShell to restore what you have pains-takingly backed up.