Monday, November 22, 2010

DPM and SharePoint 2010 Item Level Restore -- The Temporary Staging SQL Server

In writing up a post on an error in DPM 2010 SharePoint Item Level Recovery, I started thinking about the role of the SQL server used as a temporary staging location during the restore. 

It seems to me, that for all intents and purposes, DPM's Item Level Recovery is really just the SharePoint 2010 Granular Restore/Unattached Content Database recovery integrated into the DPM console.  Russ Maxwell has a great walk through of how to do a granular restore without DPM.  DPM locates the recovery point of the content database, restores the whole database, and exports the file from the unattached content database, then re-imports it into the live site.  It's much less painful than manually locating the recovery point that contains the file/record, restoring the content database and using the item level recovery, since often the bulk of the work is in finding the restore point.  The DPM console lets you browse the recovery points to find the item before you go to the trouble of restoring the content database.

Restoring without a recovery farm requires 3 temporary locations.  A directory on the Web Front End to hold the restored item temporarily in cmp form, a temporary SQL server where the content database can be restored and, of course, a location on that database server's file system where the database file will temporarily live.  Although the primary database server can be used for the temporary restore of  the unattached content database (the database name is converted to the format  DPM_GUID).  I'm still using a Non-SharePoint, Non-Production SQL server for two reasons:
1.  If your content database is big, you'll take the I/O hit of restoring the whole database to the same disks that are serving up your production farm, and could potentially run your disk out of space (but you'd check that first) just to delete it when the item is restored.
2.  The term "Unattached Content Database" does not mean it isn't attached to SQL Server, it's just not attached to SharePoint. 
I'll be testing whether this works using SQL Express as the intermediate restore database.

No comments:

Post a Comment