Desaster Recovery eines virtuellen Servers

C.Kaiser Als Antwort am 9 Nov. 2009 16:10

Ich würde mir eher überletgen ob ich nicht Snapshots von dem Datenbank-Server mache. Eine geeignete Backup Software für den SharePoint würde das übrige tun um nicht andauernt einen Snapshot wiederherstellen zu müssen, wenn User etwas "versehntlich" gelöscht haben.

Das Thema Backup und Restore ist aber recht komplex, da einige Dinge berücksichtigt werden müssen.

hep83 Als Antwort am 9 Nov. 2009 17:13

Hallo,

mit so einer schnellen Antwort habe ich nicht gerechnet :) Aber danke. Ich hatte meine Frage noch ein wenig umgestellt.

Gruß

Andi Fandrich Als Antwort am 9 Nov. 2009 17:21

Geht es Dir jetzt um Desaster Recovery oder um ein Testsystem?

Desaster Recovery ist ein weites Feld und kann nicht "einfach so" beantwortet werden. Ein Testsystem solltest Du einfach als zweite Farm (auch mit nur einem Server) aufbauen. Falls Du Sites aus dem Produktivsystem benötigst, kannst Du die einfach mit backup/restore übernehmen.

hep83 Als Antwort am 9 Nov. 2009 22:49

Hallo,

es geht mir um beides.

Zum Testsystem:

Wir haben in unserem Unternehmen 2 Domänen, eine fürs Produktive, und die andere fürs Testsysteme. Nun habe ich mir überlegt einen SharePoint Test-Server in die Testumgebung zu stellen und würde gerne den bereits vorhanden Test-SQL Server verwenden.

In einem Buch habe ich gelesen, dass bei der Bestückung eines solchen Testsystems mittels Recovery die Servernamen der Server im Produktiv und der Server im Testsystem gleich sein müssen. Ob das so stimmt ist meine Frage. Auf dem Test-SQL Server laufen nämlich auch andere Testsysteme, weshalb ich den Test-SQL Server nicht einfach umbenennen kann.

Ich habe es so verstanden, dass eine  Bestückung der Testumgebung mittles Recovery die für mich best Möglichkeit ist.

Am liebsten wär es mir, wenn ich einfach eine Kopie des virtuelln SharePoint Servers in die Testumgebung packen könnte und dann den SQL-Server in der Testumgebung mit den aktuellen Datenbanken bestücken würde. So würde ich mir ein Recovery über das stsadm programm sparen. Das geht angeblich nicht, da es Probleme mit der Konfigurationsdatenbank geben kann oder so... Stimmt das?

Zum Desaster Recovery:

Die Bestückung des Testsystems ist gleichzeitig mein Recovery Test. Da mir 24 Stunden alte Daten reichen, wäre es natürlich traumhaft, wenn ich wie gerade beschrieben einfach ne Kopie vom SharePoint Server nehmen könnte, die Datenbanken einbinden könnten (bzw. den ganzen SQL Sever wiederherstellen könnte).
Der SharePoint Server und der SQL Server werden jede Nacht bereits von unserem Rechenzentrum gesichert.

Gruß

Andi Fandrich Als Antwort am 10 Nov. 2009 08:53

Wie gesagt, ganz so einfach gezht das nicht. Die Servernamen sind an ziemlich vielen Stellen hinterlegt und lassen sich nur schwer nachträglich ändern. Du wirst mindestens mit der ConfigDB große Probleme bekommen. Wenn Du das Ganze dann auch noch in eine fremde Domäne bringst, dann sind mindestens alle Berechtigungen flöten (weil die User/Gruppen dort unbekannt sind).

Wie oben geschrieben: ich würde ein separates Test- und Entwicklungssystem hochzeiehn und mir dann einzeln das holen, was ich brauche.

hep83 Als Antwort am 10 Nov. 2009 09:11

Danke für die Antwort!
Die beiden Domänen sind mit einer Vertrauensstelle verbungen. Die Benuzterkonten sind in beiden gleich... aber ok, der Name ist natürlich ein andere.

Beim Recovery (Kopie des SP Servers starten - Kopie der Datenbanken einhängen) wär der Server aber in der alten Produktiv Domäne und die Server würden natürlich die alten , richtigen Namen haben. Ginge das denn zumindest? Test kann ich das leider nicht, da ich ja keine gleiche Testumgebung bauen kann.

Gruß

Andi Fandrich Als Antwort am 10 Nov. 2009 09:14

Nein, das geht nicht, weil es in einer Domäne nicht zwei Rechner gleichen Namens geben kann.

hep83 Als Antwort am 10 Nov. 2009 09:30

Ich muss mich genauer ausdrücken, sonst kommt es zu Missverständnissen :)

Also...

Im Recovery-Fall wäre es klasse, wenn folgendes gehen würde:

1. SQL Server und SP Server sind defekt:
    Ich entferne beide virtuellen Server aus der produktiv Domäne. Nehme mir eine Kopie (24 Stunden alt)  des SQL Servers und starte diesen. Dann starte ich eine Kopie des SP Servers, ebenfalls ca. 24 Stunden alt. Dann wäre nur "vielleicht" das Problem, dass die Kopien, die Nachts erstellt werden, nicht in der gleichen Sekunde gemacht werden - ich "habe gehört", das es da zu Problemen kommen kann. Welche weiß ich nicht. Ich weiß nicht genau wie der Sicherungsvorgang der Server in der Nacht durchgefürht wird - was gesperrt ist und so. Das versuche ich gerade bei unserem Dienstleister in Erfahrung zu bringen.

2. für die Testumgebung habe ich in einem Beitrag weiter oben quasi 2 Möglichkeiten beschrieben:

a) Die Testumgebung mit einem Recovery für das stsadm Tool befüllen. Dabei wird die ConfigDB neu erstellt, also nicht kopiert. Dennoch müssen die Servernamen in der Testumgebung laut dem Buch "Microsoft Office SharePoint 2007 - Best Practice" gleich sein - warum wird da leider nicht gesagt.

b) 2 Images von beiden Servern einfach in der Testumgebung starten - das geht nicht, wie wir herausgefunden haben, da der Domäne-Name unterschiedlich ist und der Test SQL Server anders heißt als im prod. System

Gruß

Andi Fandrich Als Antwort am 10 Nov. 2009 09:36

Zu 1) das wird nur funktionieren, wenn die beiden Kopien exakt zur selben Sekunde erstellt wurden und die Server in der Zeit absolut nichts zu tun hätten. DB-Server und Webserver müssen immer synchron sein, sonst gibt es in den meisten Fällen Probleme (hauptsächlich mit der Suche). Wenn die beiden Server für die Zeit des Backups eingefroren werden können, dann funktioniert das allerdings.

hep83 Als Antwort am 10 Nov. 2009 09:45

Hi Andi,
ob da mit dem Einfrieren funktioniert versuche ich mal rauszukriegen und poste das dann hier.

Zu 2. a)

http://windowsitpro.com/article/articleid/102572/step-by-step-sharepoint-disaster-recovery.html

Andi Fandrich Als Antwort am 10 Nov. 2009 10:41

Desaster Recovery dient zum Wiederherstellen einer nicht mehr vorhandenen (warum auch immer) SharePoint Farm und nicht zum Erstellen eines parallel laufenden Systems. Das sind einfach zwei verschiedene Dinge.