wir haben im Zuge des DPM und SharePoint Themas die folgende Konfiguration gewählt:

• SharePoint Farm mit 2 Web Frontent Servern (über NLB) (WFE1 und WFE2)
• Ein Search/Index Server (SRCH)
• Ein DB Cluster (Active/Passive) (DB)
• Eine SharePoint Single-Server Farm für die Recovery Farm (REC)
• Einem DPM Server (DPM)

Das Ganze sieht dann so aus:

Die Item-Level Recovery (am Beispiel einer Teamsite) erfolgt nun im mehreren Schritten:

1. Restore der betroffenen Content-Datenbank auf die SharePoint Recovery-Farm (REC) hier kommt der SQL VSS Writer zum Einsatz
2. Mounten der DB unter der DPM eigenen Webanwendung
3. Auf dem Recovery-Server (REC) wird ein Prozess zur Extraktion der Daten gestartet (WSSCmdletsWrapper.exe)
4. Die extrahierten Daten werden auf dem Recovery-Server (REC) im Dateisystem abgelegt
5. Per Filesystem VSS Writer werden die Daten in die produktive Farm kopiert (auf WFE1 oder WFE2)
6. Auf dem produktiven Web Frontend (WFE1 oder WFE2) wird ein Prozess zum Datenimport (WSSCmdletsWrapper.exe) gestartet um die Daten in die Produktionsfarm zu importieren

Für den WSSCmdletsWrapper der hier ja eine Schlüsselrolle spielt wird für den Export/Import von/nach SharePoint die Deployment API verwendet (Link)

Falls mal was schiefgeht

Leider ist das Exception-Handling in Richtung DPM recht informationsarm, es wird sobald was im WSSCmdletsWrapper schief geht ein "Unknown Error" geloggt, sonst nicht allzu viel.
Das ist aber nicht alles: wenn man die oberen 6 Schritte durchgeschaut hat sieht man dass SharePoint APIs verwendet werden - und die loggen sehr wohl in die SharePoint Logs unter %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Logs

Happy restoring

Sven