From The Field

Intro

I chose to delay this blog series so I could speak about DPM 2010 and SharePoint 2010 openly once the betas were made available!

By now everyone should know the pros and cons of SharePoint and DPM 2007 when it comes to backup and recovery, not least the need to have a recovery farm. I’m pleased to say that the requirement for a recovery farm in SharePoint 2010 is now gone! The real technical specifics of this can be found on MSDN. This also means DPM no longer needs a recovery environment and can recover SharePoint 2010 content faster and easier than ever before.

Enhancements

Since this blog is not aimed at marketing, I will just list the key enhancements below and let you decide for yourself if the new product enhancements are cool:

·         No need for a recovery farm (SharePoint 2010 feature).

·         Automatic protection of new content databases (without the need for a consistency check – DPM 2010 feature).

·         Scheduling of the SharePoint catalog job (which enables item level recovery – DPM 2010 feature).

·         There are also many non-SharePoint enhancements all of which can be found on the DPM product groups blog here: http://blogs.technet.com/dpm/archive/2009/09/29/DPM-2010-beta-is-available-now.aspx!

And yes you can still protect previous versions of SharePoint with DPM 2010!

2010 Item-Level Recovery Walkthrough

Since the protection group and recovery point creation process is the same as it was in DPM 2007, I’ll avoid showing that here. In addition recovery of databases and high level items like the entire farm is the same. Therefore I will focus on the item level recovery process for SharePoint 2010 by using DPM 2010.

Note: You do not get this option for a MOSS 2007/WSS 3.0 farm, as unattached database recovery is a new feature in SharePoint 2010.

 

You should choose the ‘without using a recovery farm’ option if you are restoring from a backup that is the same version as the production farm. If however you were restoring content that was backed-up prior to an update (service pack or cumulative update for example), you should choose the option to use a recovery farm.

 

You may be wondering why you still need a recovery farm when recovering content from an old SharePoint build. This is because the unattached database recovery method will restore a copy of the database with the content you wish to restore and then use the new API allowing unattached extraction of content from a SharePoint content database. As a result, the content is NOT upgraded to the production farm version and may cause corruption if restored.

 

When using a recovery farm (the old way), the database is actually attached to a SharePoint farm and part of that process involves upgrading the database and all its content to the current version of the farm (and as you know recovery farms must be the same version of the production farm). This is a lot slower but guarantees the content is at the correct version level before being exported out of the database and re-imported back into the production farm.

 

It may be easier to visualise this:

 

 

It is worth noting that this diagram does not show exact communication paths and ordering but is merely an aid to show data flow during the 2010 item-level recovery process. If you can’t remember how data flows when using a recovery farm, see part 3 of this series.

 

Once you have chosen the recovery process you wish to use, you will be asked to specify a temporary server which is used as shown in the diagram above:

 

 

Notice how you are not asked for a recovery farm Web front end server when you choose to perform an unattached database restore (recovery without a recovery farm). You are just asked for a SQL instance and the location to store the database files during the recovery process.

 

Next you are asked for a staging location on the production WFE. This will be used to extract the files from the recovered database and then import them into the production database.

 

 

You are then given the standard recovery options window where you can choose whether to restore security settings, use network bandwidth throttling, enable SAN based recovery and provide notification upon recovery completion. This has not changed from DPM 2007. The recovery summary window is given and the recovery starts when you click on Recover. I have not shown these stages as they do not differ from DPM 2007.

 

Finally, it is worth mentioning that DPM 2010 now includes the export and import logs that SharePoint can generate when using the content migration API. These are stored in the temporary folder that you specify when performing a recovery. This makes troubleshooting much easier than described in part 4 of this series.

 

You also get much better detail about what DPM is actually doing with SharePoint in the DPM Jobs window:

 

 

That’s it; you should now be able to recover SharePoint content faster than ever before. Roll on DPM 2010 and SharePoint 2010!