Benutzer mit den meisten Antworten
Test Szenario - Exchange 2010 Komplettausfall

Frage
-
Hallo zusammen,
ich lese schon länger hier im Forum und habe bisher immer eine Antwort auf mein Problem gefunden, aber irgendwann kommt der Zeitpunkt da muss man selber mal ran ;-).
Zu meiner Person:
ich bin Admin in einem kleinen mittelständigen Unternehmen und betreue u.a. einen virtualisierten Exchange 2010 Std (CAS, Hub, Mailbox) mit ca. 60 Postfächern auf Windows Server 2008 Basis.Momentan beschäftige ich mich mal wieder mit der Desaster Recovery und hänge fest (oder mein Denkansatz ist falsch):
Das Backup der Windows Server (Active Directory, Fileserver, Exchange etc.) läuft über Windows Server Backup (jede Nacht Full Backup auf ein Netzlaufwerk).
In einer isolierten virtuellen Umgebung habe ich schon mehrmals den Ernstfall geprobt und bspw. das Active Directory (2x DC) und auch den Exchange zurückgesichert (bei allen komplette Server Wiederherstellung per Windows Server CD und Auswahl der VHD vom Netzlaufwerk).
Der Exchange wäre nach der Rücksicherung und arbeitendem AD wieder einsatzbereit, allerdings mit dem Stand der Datenbank von letzter Nacht.
Wie kann ich die Transaktionsdateien in die Datenbank einspielen um wieder auf den aktuellen Stand zu kommen?
Da ich diese nicht in die eingebundene Datenbank einspielen konnte (Unwissen meinerseits nicht ausgeschlossen), habe ich exakt dieselbe Datebank ein zweites Mal zurückgesichert und als RecoveryDB mit den aktuellen Transaktionsdateien eingebunden. Das hat funktioniert, allerdings ist es nicht sehr praktikabel die Datenbank zweimal zurücksichern zu müssen.
Ist der Ansatz falsch?
Könnte die Setup Option "Setup /m:RecoverServer" die Lösung sein? (habe sie bisher nicht getestet)
Welche Möglichkeiten hätte ich sonst?
Vielen Dank im Voraus...
Gruß
Sascha
Antworten
-
Moin,
Desaster Recovery ist zu kompliziert, um es in einem Forum wirklich erklären zu können.
Was Du brauchst, ist ein "Hard Recovery".
Hier ist beschrieben, was damit gemeint ist:
http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/
Grüße aus Berlin schickt Robert
MVP Exchange Server- Als Antwort markiert Alex Pitulice Donnerstag, 16. Mai 2013 07:40
Alle Antworten
-
Moin,
Desaster Recovery ist zu kompliziert, um es in einem Forum wirklich erklären zu können.
Was Du brauchst, ist ein "Hard Recovery".
Hier ist beschrieben, was damit gemeint ist:
http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/
Grüße aus Berlin schickt Robert
MVP Exchange Server- Als Antwort markiert Alex Pitulice Donnerstag, 16. Mai 2013 07:40
-
Moin,
Desaster Recovery ist zu kompliziert, um es in einem Forum wirklich erklären zu können.
Was Du brauchst, ist ein "Hard Recovery".
Hier ist beschrieben, was damit gemeint ist:
http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/
Grüße aus Berlin schickt Robert
MVP Exchange ServerHi Robert,
danke für den Tipp.
Problem dabei dürfte sein, dass ich keine restore.env-Datei habe. Da ich mir damals nicht anders zu helfen wusste, habe ich ein Powershell-Script gemacht, dass mir regelmäßig die Transactions Logs wegkopiert. Die liegen auf meinem Netzlaufwerk und warten darauf benutzt werden. -
Moin,
dann wäre es ein Soft Recovery. Ist nur ein anderer Schalter in eseutuil (/r), im Prinzip aber das gleiche: Alle Log-Dateien wieder einspielen.
Grüße aus Berlin schickt Robert
MVP Exchange ServerGenerell weiß ich wie man Log-Dateien in die Datenbank einspielt (spätestens nach deinem Link ;-).
Aber in meinem Szenario läuft es doch dann auf eine separate Wiederherstellung der Datenbank und Einbindung als RecoveryDB hinaus, oder?
Ein Einspielen der Logs in die eingebundene Datenbank aus der Serverwiederherstellung ist nicht möglich?Ich bin schon länger auf der Suche nach einer Antwort auf dieses Szenario, habe aber bisher keine Quelle gefunden, die das behandelt. Insofern behaupte ich, dass der Ansatz falsch ist... falls du andere Ideen hast: ich bin für alles offen :-)
Danke und Gruß
Sascha -
Moin,
Generell weiß ich wie man Log-Dateien in die Datenbank einspielt (spätestens nach deinem Link ;-).
Aber in meinem Szenario läuft es doch dann auf eine separate Wiederherstellung der Datenbank und Einbindung als RecoveryDB hinaus, oder?das ändert aber nichts daran, dass Du die Datenbank VORHER in den Status "Clean Shutdown" bringen musst. Ob die dann als normale DB oder RecoveryDB installiert wird, ist egal.
Ein Einspielen der Logs in die eingebundene Datenbank aus der Serverwiederherstellung ist nicht möglich?
Nein, eingebunden darf die nicht sein. Aber für ESEUTIL ist es egal, voher die Daten kommen und wo sie liegen. ESEUTIL kann man mit Schaltern sagen, welche Dateie es benutzen soll. Und wenn alles da ist, hat man am Ende eine saubere EDB.
Theoretisch kannst Du die Daten mir geben (USB-Platte), ich lasse bei meinem Exchange ESEUTIL drüber laufen und danach ist die Datei für Dich verwendbar, ESEUTIL ist ein Lowlevel-Tool.
Ich bin schon länger auf der Suche nach einer Antwort auf dieses Szenario, habe aber bisher keine Quelle gefunden, die das behandelt. Insofern behaupte ich, dass der Ansatz falsch ist... falls du andere Ideen hast: ich bin für alles offen :-)
Das Problem ist eigentlich wie immer: Du musst Deine WIEDERHERSTELLUNGS-Anforderungen definieren. Daraus leitet sich dann die Sicherung un der Wiederherstellungsprozess ab.
Und dieser Prozess ist je nach Wiederherstellungs-Anforderung unterschiedlich.
Beim Totalausfall eines kompletten Servers würde man z.B. Recover Server und Restore machen.
Du bringst aber immer sofort noch andere Faktoren ins Spiel - z.B. alles Weg, aber Log-Dateien noch da. Und sofort ändern sich Recovery-Mechanismen.
Das ist auch der Grund, warum Du keine einfach Anleitung findest: Es gibt keine, die auf alle Szenarieren einfach so passt. Jeder Infrastruktur ist anders und das Recovery muss für diese Struktur ausgelegt sein.
Am besten holst Du Dir einen Fachmann ins Haus, spielst das mit dem durch und protokollierst dabei gleich alles. Dann hast Du alles für DEINE Umgebung aufgeschrieben.
Das dauert aber problemlos 3 bis 5 Tage.
Grüße aus Berlin schickt Robert
MVP Exchange Server