SharePoint Data Protection : Page 2

SharePoint Data Protection

If you have already deployed SharePoint, it's not too late—just make sure you take action as soon as possible, because your SharePoint data is only as good as your most recent backup. Out of the box, SharePoint includes a couple of options for protecting the data. The first method is a three-step process:

1. Back up the SQL Content databases regularly. You can use native SQL tools or your SQL backup software of choice to perform regular backups of the content databases.
2. Restore the databases. When data loss occurs, the restore process involves first restoring the content databases onto the SQL Servers, and then recreating your SharePoint web applications with the same settings that were configured when the database backup was taken.
3. Re-associate databases with applications. Finally, you will need to associate the restored content database with the newly-created SharePoint web applications.

If you decide to use this backup method, you must make sure to document your SharePoint configuration thoroughly. It’s also important to include IIS configuration information in your SharePoint documentation.

The second built-in backup method involves using SharePoint's native backup tools. You'll find these tools in a "Backup" section within the Central Admin application, and there are also some command line utilities that you can script. The primary advantage of using the native SharePoint backup tools is that you they can backup and restore your entire SharePoint farm configuration. When you need to restore of the farm, you can perform a fresh install of SharePoint, and then restore data and configuration information straight from Central Admin or a script.

The native tools let you backup things you might miss using SQL backups, such as Shared Service Providers (SSPs) and search configurations. They also make it easy to choose which web applications, content databases, and configurations you want to backup.

Regardless of which method you select, you should perform regular restores to a test environment to check the backup plan. If you can’t restore the data, backups are useless. As you do so, document the entire recovery process, so that when a real emergency restore situation occurs, you won't have to guess which step to perform next. The SharePoint restore process is also a great way to build test and dev environments that mimic your production deployment. You can quickly configure and perform a backup of your entire farm or individual components by performing the following steps:

Figure 2. SharePoint Central Administration Backup: Using the Central Admin backup tools, you can select the components and databases you wish to back up.

1. Log onto one of your web front-end servers.
2. Open Central Admin and select the Operations tab.
3. Click the "Perform a Backup" link (see Figure 2).
4. Select the components or databases you wish to backup. Then click the "Continue backup options" link.
5. Choose the backup type and location. Select a full backup to back up all of the selected components. Select a differential backup if you want to back up only the data that has changed since the last full backup was performed.
6. Choose a file share where you want to save the backup, and then click OK.

You can monitor the backup progress in the Central Admin console. After the backup completes, verify there were no errors.

Increase Safety with Offsite Data Replication

If your organization has a formal disaster recovery plan, you may replicate critical applications to a secondary data center. In the event of a disaster such as a flood or fire at the primary data center, you would fail-over to your secondary data center. You may want to include SharePoint in the list of applications to replicate to the secondary data center.

You can accomplish this using SQL log shipping to send the SQL transactions logs from the production SQL server to a stand-by SQL server in your secondary data center. Log shipping is a SQL server technology that copies transaction logs from one server to another—either on a local network or over wide area network (WAN) links. Log shipping is supported only for the content databases; therefore, in the event of a disaster, you will need to have a SharePoint farm set up in the secondary data center and manually configured to match the primary data center. Like your backup plan, you should thoroughly test and document the procedures as part of your SharePoint deployment. To setup SQL Log Shipping to provide disaster recovery, perform the following:

1. Setup a duplicate copy of your SharePoint farm at the disaster recovery (DR) site. Be sure to duplicate any customizations you might have made to your farm's configuration.
2. Take a backup of your content databases from your production environment and restore them to the DR site.
3. Setup SQL Log Shipping on content databases to send transaction logs from your primary SharePoint farm to the DR SharePoint farm. Keep in mind that the content databases in the DR farm are in read-only mode while logs are being shipped.

In the event of a disaster you would need to bring the databases out of standby/read-only mode and update your DNS records to point to the new SharePoint farm.

Planning for backups, availability, and disaster recovery is a critical step in deploying SharePoint. It’s also important to test and document these processes on a regular basis. You will sleep better at night knowing you have a well-tested SharePoint protection plan in place.

Useful Links

• Microsoft Office SharePoint Server 2007 Best Practices, by Bill English and Ben Curry, Microsoft Press, 2008.