Now that the initial excitement about the sneak preview of SharePoint 2010 features calmed down, let's take few minutes and look closer at some of them. Specifically, today we'll try to see what changes are there in the new SharePoint version for content backup and recovery. We'll discuss what's coming in SharePoint 2010 for data recovery, how this can simplify operations, and how to make sure you maximize return on your current investments in this space, considering the new features ahead.
The big new feature highlighted by Richard Riley in the IT Pro video is, of course, the unattached content database recovery. This means that SharePoint administrators can mount a copy of SharePoint content database, browse its contents (down to a list or document library) and export site collections, sites and lists into CMP files.
The other change you may notice during the new Central Admin interface demo is that now the good old STSADM site collection backup is also available from the web user interface. Notice the ‘Perform a site collection backup’ action under the Backup and Recovery category.
These changes basically mean that SharePoint approach to backup and recovery does not dramatically change in the new release. Site collection level backups seems to still be the recommended way to ensure you can granularly restore the content, so SharePoint stays the only Microsoft technology that suggests you need duplicate backups of the same data (e.g., database backup and site collection backup) for different recovery scenarios.
At the same time, granular SharePoint data recovery from SQL content database backups found its way into the new release and thus becomes industry standard. With SharePoint 2003 and 2007 this is only possible if you maintain an additional recovery farm where you can attach the content database from backup, then browse to the data you need and export it. The process requires you to get and restore the right SQL database backup, sometimes involving SQL DBA and/or backup operators to retrieve it. Unattached content database recovery in SharePoint 2010 is very similar to some of the 3rd party offerings, such as SQL Restore Controller recently released by AvePoint: both eliminate the need for maintaining the recovery farm, which will definitely save time and efforts in a recovery exercise. However, overall the functionality is still very basic and all the other steps you need to take stay the same, requiring considering time, efforts and cross-team coordination.
The concept of granular SharePoint data recovery from the content database backups was first introduced by Quest in our Recovery Manager for SharePoint over two years ago, and few other ISVs followed this concept recently. Unlike some other offerings though, Quest Recovery Manager is primarily focused on the importance of minimizing the time to restore. The product is designed to fit the backup process, allow for role separation, and make locating the content that needs to be restored as quick and easy as possible.
The new backup and recovery features that come with SharePoint 2010 will simplify basic recovery scenarios and are definitely a step forward for anyone who can afford to rely on the native tools only. However, companies that store critical data and run business applications on SharePoint will still want to consider 3rd party tools to ensure they spend minimum time to restore content, be that a single document, a list, or an entire site collection.