I've been working on a whitepaper for Quest (for a while) which focusses on Sharepoint Recoverability from a DBA's perspective.

As you proably know Sharepoint uses SQL Server to store its data, and although the data structures and usage within the SQL Server databases isn't what a DBA would call "optimal" its heavy use of tables etc brings things such as Performance Tuning, Capacity Planning and Disaster Recovery into the realms of the DBA as a relatively "complex" database application.

I've spoken to some MS folks and MVP's on some of the current gaps we've got for a method or two I've been trying to code and document for the paper, mainly around binding the various databases LSN's ([Transaction] Log Sequence Numbers) to time as a base in order to create restore paths that cater for the control type databases and the other content and component type databases.

The latest info I got from Mike Epprect from MS Switzerland (thanks Mike!) is that although the info isn't available to the DBA from the internal data structures, DMV's and Backup tables, MS's Data Protection Manager (DPM) handles this and the out of SQL Components as well such as the various files that need to be in synch for recoverability.

I'll be looking in to it and doing some tests around it to work out how well it handles all of this and also so see if we can bring it closer to the DBA neutral perspective of looking after database recoverability for Sharepoint, Biztalk et al as normal DB Applications.

Let me know if you've done this before or if you've got any gotchas that will same me what little time I have these days.