Backup and Restore Strategies in MOSS 2007

SharePoint is an incredible platform. It is all about a good return on investment for your clients. It lets you put together and deliver very compelling solutions with ease. It is thus not hard to imagine why a lot of clients get addicted to this good return on investment and misinterpret it as “Hey, it’s cheap!” and completely ignore long term planning of what they are addicted to.
They might ignore, but you shouldn’t, and lucky for you there are well defined mechanisms to perform backups and restore of your SharePoint environments. In this article, I will talk about the various standard mechanisms available to you as a SharePoint developer or administrator to perform reliable backups of your environment.

Backup using Central Administration

This is probably the simplest and most straightforward mechanism of performing backups and restores of your SharePoint installation. Under Central Administration à Operations, you would see an entire section for backup and restore as shown below:

Using this interface is quite straightforward, for instance, to perform a backup, click the top link titled “Perform a backup” and you are presented with a user interface similar to as shown below.

Over here, you would simply check-mark the portions of the farm that you intend to backup, and click on the “Continue to Backup Options” button. In step #2, you are presented with the following screen:

As you can see, this UI will let you specify a full or a differential backup, and all you need to do is supply a network location where the farm account has sufficient read/write writes, and your entire farm is easily backed up as a single file. You even get an estimate of what the backed up file size would be. This approach is dead simple, but the obvious problem here is that there is no straightforward way to automate this.

Backup using stsadm

I love GUIs. GUIs get me started on the basic tasks I need to accomplish to keep myself out of trouble. For instance, when I was learning SharePoint, I did realize that backup is an important aspect, and the dead straight UI made my learning curve a lot easier. But soon enough I got bored of performing all those clicks on a daily basis, so I wanted to script the backup process. As it turns out, stsadm.exe will allow me to backup individual sites and site collections very easily.
In order to backup a site collection, you can use the following command:

stsadm –o backup –url -filename

Similarly, to restore a backed up file to a site collection, you may use the following command:

stsadm –o restore –url -filename

Similarly, to backup a single site, you may use the following command:

stsadm –o export –url -filename

In order to restore a single site at any URl, you may use the following command:

stsadm –o import –url filename

Seems quite straightforward, but there is more to it than meets the eye. For starters, backing up individual sites, isn’t exactly backing up a site. It queries the site using the object model and stores everything the site had that was exposed using the front end UI, into the given file. By default, you might miss older versions of files in a document library that has versioning turned on. You can however specify command line parameters to these commands to influence further control on how older versions are backed up. Also, this approach is quite arduous for a farm with a number of sites. Most of all, stsadm can error out at times, and the error can show up on command line, or even worse, the command line may tell you that it worked, but an error may show up in a log file somewhere. So even though this approach is scriptable, making it 100% bullet proof is still somewhat of a problem.

Backup using database backups

This is probably the approach you will end up using most often. SharePoint stores all its data in SQL Server. Also, a site, or site collection, is nothing but data. Thus it is reasonable to assume that this data, can be easily backed up and restored using standard SQL Server mechanisms.
SharePoint stores its data in content databases. A single website can have a number of content databases, and a content database can contain one or more site collections. In other words, you cannot scope a content database to a single site or single list level.
You can view all the content databases associated with a given web application under central administration à Application Management à SharePoint Web Application Managementà Content Databases. This can be seen as below:

From this screen, you can add or remove content databases to a given web site. When you add a content database, you have the facility of specifying a database server and a content database name. If the database already exists on the server, it will be used as is. If in case the database does not exist on the server, it will be created for you by the farm account.
You can use this behavior to your advantage to backup restore web sites. In order to backup a web site, you simply backup all the content databases associated with the web application. In order to restore a website, you restore the content databases, and perform the extra step of specifying new site collection administrators in the new environment.
This is a fairly robust mechanism of backing up and restoring your SharePoint environment and I suspect that in any serious installation, this is what you will end up using the most anyway. This by far, however is not enough. Depending upon the specific needs of your SharePoint environment, also want to invest in the following:

1. Backup the entire 12 hive (c:\program files\common files\microsoft shared\web server extensions\12). This is because, frequently you will deploy code to your SharePoint farm, and you will need to restore the supporting physical files for the site to work properly.
2. You need to keep monitoring the size of your content databases. If you start hitting the 50GB mark, think of splitting them up, so the backups are done overnight before users start hitting the database in the morning.
3. Backup the entire INETPUB directory.

4. Always maintain a path to restore the current state of the production environment as various releases are pushed into production. This can be achieved by following the below recommendations:
a. Always use a scripted deployment process with clear instructions for deploying code to production. Give special attention to ensuring releases capable of taking your SharePoint installation from one version to another. With various releases, your scripts and instructions should be capable of taking a fresh SharePoint installation to the current production state.
b. Always deploy custom code as solutions, not fragile xcopy scripts.
c. Backup source control databases, and establish a strong version control policy for all code that goes into production.
d. Document all customizations and administration done under central administration for every release.
e. Follow standard disaster recovery best practices, such as regular and verified backups, off-site storage etc.
f. Backup Shared Service providers and Central Administration using stsadm after every significant configuration change or production release.

Backing up shared service providers

You can backup and restore an SSP in a mechanism similar to restoring any other SharePoint website. You must however perform the additional step of associating the SSP with the appropriate web applications after such a restore has been performed. This may be achieved using the following steps.

1. Under central administration, click on the “Shared Services Administration” on the left side of the page.
2. Once on the “Manage this farms shared services” page, click on “Restore SSP”.
3. Now assuming that you have already restored the SSP on a site, complete the required fields on the page shown. Just make sure that you specify the restored web application and database that the SSP site has already been restored to.

Backing up search

Search is probably the weirdest portion to backup on a SharePoint installation. First of all, given the additional complexity that backing up search requires, it might be a good idea to go with rebuilding the indexes for small or even medium sized farms. However, if your search database is huge, and your farm is quite big, and you need search to be online shortly after a disaster, you will need to look into an appropriate strategy for backing up search.
The reason backing up search is different than other portions of SharePoint, is because of how search works. Search data is stored in two locations, the search database, and the index files on the disk. You need both in order to be able to successfully serve search queries. Not only both, but you need both of them backed up concurrently for the restored versions to work together. In other words, if the search index was backed up 5 minutes after the search database, the index entries created in the additional 5 minutes will cause inconsistent results in the restored search.
In order to ensure this consistency, you should backup search using SharePoint 2007’s backup tool, or a third party product.

Conclusion

Backups are terribly important, do not ignore them. This article introduced you to various aspects of backing up your SharePoint farm. As you can see, you have a gamut of choices to pick from, and depending upon your environment you may want to pick the right combination of these choices that fits your needs the best.

Print this post