nachdem ihr in diesem Post mitbekommen habt bin ich dabei eine Muster-Implementierung des Data Protection Managers mit dem Microsoft Office SharePoint Servers durchzuführen.

Hier nun die Zusammenfassung und meine persönlichen Lessons learned in Stichpunkten

Gesamtes Setup

Im Wesentlichen haben wir 2 Komponenten die aufgesetzt werden müssen. Der DPM Server an sich und die Remote-Agenten.

DPM Server

An sich ein Setup (mit CD rein, SETUP.EXE) jedoch bleibt hier zu bedenken dass es sehr ratsam ist die DPM eigene Datenbank auf demselben Server zu haben.
Die Storage für die Backups muss als ein (oder mehrere Volumes) unformatiert vorliegen. Das Handling (Partitionen, Storage Pool) übernimmt DPM

Agenten

Wenn die Voraussetzungen erfüllt sind können die Agenten problemlos installiert werden. Hierbei ist es wichtig Agenten auf folgende Server SharePoint Farm zu installieren.

  • Datenbank Server (bei Datenbank-Clustern auf ALLE Cluster-Nodes)
  • Search/Index (ALLE Server die diese Rolle haben)
  • Alle Web Frontend Server

Die Verbindung zwischen dem Agenten und SharePoint wird durch ein Tool (ConfigureSharePoint) hergestellt. Dies darf nur auf EINEM Web Frontend Server geschehen.

Setup der Recovery Farm

Die Recovery-Farm wird nur gebraucht wen SharePoint Item-Level Restore benötigt wird. Hier tut es eine Single Server in einer eigenen Farm. Es gibt jedoch etwas zu beachten:

  • Die Storage an dem Serrver muss die größte Content-Datenbank aus der Produktions-Farm aufnehmen können (plus etwas Platz als Reserve)
  • Die Basic-Installation reicht nur bedingt wenn große Content-Datenbanken im Einsatz sind. Wir haben die Complete-Installation auf SQL 2005 Standard gewählt.
  • Die Recovery Farm darf sonst für nichts anderes verwendet werden
  • Der Patch-Level muss ser Produktions-Farm entsprechen
  • Die Webanwendung für den DPM genau nach Dokumentation anlegen (Namen sind Case-sensitiv)
  • WSPs aus der Produktions-Farm müssen für die DPM Webanwendung installiert und Features aktiviert sein

 

WSPs und andere Anpassungen

spätestens jetzt rächt es sich wenn man Anpassungen auf der Produktionsfarm ohne WSP deployment vorgenommen hat. Man kann natürlich die Anpassungen auch manuell auf der Recovery-Farm machen, aber wenn man sich vertut ....

Wenn die WSPs konsistent auf Produktions und Recovery-Farm installiert und die Features aktiviert sind machen diese keine größeren Probleme.

 

Restore einer kompletten Farm

wir sind wie folgt vorgegangen:

  • Zerstören der Farm durch PSConfig und herausnehmen aller Server aus der Farm
  • Löschen aller SharePoint relevanten Datenbanken auf dem Datenbank-Cluster
  • Gründen einer neuen temporären Farm
  • Recovery der alten Daten mit DPM
  • Zerstören der temporären Farm
  • Zuordnen der Servern zur ursprünlichen Farm mit PSConfig

Folgende Learnings haben wir mitgenommen:

  • exakten Patchlevel zum Recovery-Point wiederherstellen. Sonst kommt man zwar recht weit, beim letzten o.g. Schritt passieren jedoch unvorhergesehene Dinge (Cannot connect to configuration Database, Webanwendungen werden nur teilweise angelegt .....) auf jeden Fall gibt es einen SchemaValidateion Error in den Logs - auf jeden Fall anschauen.
  • Die Recovery Farm braucht`s für den Farm-Restore nicht
  • WSPs müssen direkt nach dem Restore nachgezogen werden (falls diese Modifikationen im Filesystem durchführen)
  • die temporäre Farm braucht es wirklich um die Webanwendungen anzulegen .. also das ist keine Arbeitbeschaffungsmaßnahme

 

Item-Level Restore

Die gesammelten Erkenntnisse würden diesen Blog-Eintrag sprengen, daher gibt es für diesen Punkt einen eigenen Post

Restore to Alternate Site

  hat mich fast in zur Verzweiflung getrieben - egal was und wie ich die URL angegeben habe, es gab immer einen "Unknown-Error". Zur genauen Übersicht habe ich mal den Post (Item Level Restore im Detail).

Key ist: Der relative Pfad muss zu 100% stimmen - verwirrt ? - ein Beispiel:

Ursprungs-Site: http://sharepoint.litwareinc.com/Teamsite1

Alternate Site: http://sharepoint.litwareinc.com/Teamsite2

Das wird nicht funktionieren, da ich die Site nicht umbenennen darf (die Site-URL ist Teamsite1), die URL im Restore muss nach dem Servernamen exakt gleich sein

Ursprungs-Site: http://sharepoint.litwareinc.com/Teamsite1

Alternate Site: http://sharepoint.litwareinc.qs/Teamsite1

das wird gehen.

Leider ist das nicht nur bei Teamsites so, sondern auch bei Dokumentenbibliotheken, Dokumenten etc.

Noch`n Beispiel

Ursprungs-Dokument: http://sharepoint.litwareinc.com/Teamsite1/Doclib/Folder/Dokument1.doc 

Folgendes wird funktionieren:

Ziel-Dokument: http://sharepoint.litwareinc.qs/Teamsite1/Doclib/Folder/Dokument1.doc (die Eingabe der Alternate Site beim Recovery-Prozess wäre http://sharepoint.litwareinc.qs)

Voraussetzungen:
Teamsite1 ist auf http://sharepoiint.litwareinc.qs existent (selbes Template)
Doclib1 ist exisitent
Folder ist existent


Was nicht geht (wird in einem unknown-Error enden):
Ursprungs-Dokument: http://sharepoint.litwareinc.com/Teamsite1/Doclib/Folder/Dokument1.doc 

Ziel:

http://sharepoint.litwareinc.com/Teamsite1/Doclib/Folder/Dokument2.doc  
http://sharepoint.litwareinc.com/Teamsite1/Doclib/Folder3/Dokument1.doc  
http://sharepoint.litwareinc.com/Teamsite1/Doclib/Dokument1.doc  
http://sharepoint.litwareinc.com/Teamsite2/Doclib/Folder/Dokument1.doc  

Daher bei JEDEM unknown-Error die SharePoint Logs auf der Recovery und der Produktions-Farm checken - diese stehen unter %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Logs

Somit ist der Nutzen der "Restore to alternate site" doch sehr eingeschränkt.

So ist doch etwas länger geworden - trotzdem: Happy restoring

 

Sven