Recovery Storage Group

Achtung:
Sichern Sie ihren Exchange Serverüber Schattenkopien, dann können Sie diese Sicherungen NICHT in eine Recovery Storage Group restaurieren und auch nicht auf andere Datenträger umleiten. Dies geht erst mit Exchange 2007. Siehe auch BackupExtrem

RSG und Exchange 2007
Auch Exchange 2007 unterstützt Recovery Storage Groups. Allerdings ist die komplette Bedienung in ein eigenständiges Programm in der Toolbox gewandert. Sie können die RSG nicht mehr in der normalen Liste der Datenbanken sehen.
Auf deutschen Servern sollten Sie zudem die Umlaute im Namen der Speichergruppe entfernen, damit die Skripte funktionieren.

Seit Exchange 2003 gibt es die "Speichergruppe zur Wiederherstellung". Mit dem Exchange 2003 SP1 hat Microsoft noch mal eine Verbesserung nachgelegt. Und das haben Sie als Administrator davon:

Das Problem

Bis zur Einführung der der Recovery Storage Group war ein Schreckgespenst für den Administrator eine gelöschte Mail im Postfach eines Anwenders. Nicht immer kann man diese Mail einfach über "gelöschte Objekte" oder den Serverpapierkorb zurück holen. Einige Löschvorgänge des Anwenders sind unumkehrbar, z.B. wenn die Mail per POP3 herunter geladen wird oder mit "Umschalt-Entf" gelöscht wird. Einige Benutzer löschen ihre Papierkorb am Ende des Tages oder Sie als Administrator haben die Haltezeit für gelöschte Elemente zu Kurz oder sogar auf 0 Tage eingestellt.

In all diesen Fällen gab es nur zwei Möglichkeiten, die gelöschte Information wieder zu erhalten:

Die erste Alternative bedeutete die zeitaufwändige Installation eines Servers mit den richtigen Parametern. Für die zweite schnellere Alternative fallen Lizenzgebühren an.

Funktionsweise und Voraussetzungen der RSG

Die Recovery Storage Group entschärft dieses Problem, indem eine frühere Sicherung der Mailboxdatenbank auf ihrem produktiven Exchange Server restauriert wird. Dabei wird aber die produktive Datenbank nicht beeinträchtigt. Über eine spezielle Version von Exmerge oder seit Exchange 2003 SP1 auch mit der MMC können Sie dann den Inhalt einzelner Mailboxen aus dieser Datenbank in die produktive Datenbank übernehmen. Allerdings muss dazu gelten:

Wenn diese Voraussetzungen erfüllt sind, dann ist der Schritt zur Wiederherstellung einer Mail relativ schnell erfolgt.

Die Anwendung

Und so wird es gemacht:

Anlegen der Speichergruppe

Zuerst müssen Sie mit dem Exchange System Manager auf einem Server eine neue "Speichergruppe zur Wiederherstellung anlegen.

Passen Sie die Pfade unbedingt an ihre Festplattenstruktur an. Es wäre nicht der erste Server, bei dem eine große Datenbank auf die Systemfestplatte restauriert wird.

 Hierbei müssen Sie aus einer Auswahl von in der Organisation erlaubter verfügbarer Speichergruppen die auswählen, welche Sie wiederherstellen wollen.

Im nächsten Schritt wird die Datenbank zur Wiederherstellung hinzu gefügt.

Der Assistent bietet ihnen dann eine Liste der zur Wiederherstellung verfügbaren Datenbanken an.

In diesem Beispiel ist nur eine Datenbank verfügbar. Auch hier wird noch einmal klar angezeigt, welche Version der aktuelle Server hat (7226) und dass nur Datenbanken restauriert werden können, die mindestens Exchange 2000 SP3 haben aber nicht höher sind als der Exchange Server selbst. Eventuell müssen Sie daher ein Update ihres Exchange Servers auf den gleichen Stand des Quellservers einer Datenbank machen.

Auch hier müssen Sie die Pfade zu den Datenbanken prüfen, da dort beim Restore eine entsprechende Datenmenge abgelegt wird:

Damit sind die Vorbereitungen abgeschlossen.

Restore der Datenbank

Im zweiten Schritt restaurieren Sie mit ihrer Datensicherungssoftware die Datenbank von ihrem Online Backup. Keine Angst, die produktive Datenbank wird nicht überschrieben. Hier greifen gleich drei Schutzmechanismen:

Ihre Datensicherungssoftware ist allerdings wirklich der irrigen Annahme, die produktive Datenbank zu restaurieren. Lassen Sie sich dadurch aber nicht in die Irre führen.

Nachdem die Datenbank wiederhergestellt ist, müssen Sie diese nur noch online nehmen.

Die Datenbank sollte problemlos starten. Wenn Sie neben den Vollsicherungen auch inkrementelle oder differenzielle Sicherungen fahren, kann es notwendig sein, vorher auch diese zu restaurieren, damit die Protokolldateien (Transaktionsprotokolle) vorhanden sind. Im Eventlog finden sich meist ausreichend Hinweise, wenn die Datenbank nicht starten will.

Übernehmen der Inhalte

Sobald die Datenbank online ist, können Sie im Exchange System Manager die betreffende Mailbox suchen und über "Exchange Aufgaben" kommen Sie an den Assistenten (Nur ab Exchange 2003 SP1 !!!).

Einzige Option ist die Wiederherstellung von Postfachdaten.

Nach der Auswahl bzw. Bestätigung des Zielpostfachspeichers im nächsten Fenster.

müssen Sie die Art der Wiederherstellung auswählen:

Hierbei haben Sie die Wahl zwischen:

Exchange übernimmt dabei:

Nicht übernommen werden aber

Diesen Schritt können Sie für weitere Postfächer wiederholen. Der Assistent bietet ihnen dann noch die Option an, den Start bis zu einem bestimmten Zeitpunkt zu verzögern, so dass Sie theoretisch die Konsole sperren und nach Hause fahren können. Diese an sich nette Funktion beim Migrieren von Anwendern auf einen anderen Server ist in diesem Fall eher selten im Einsatz.

Aufräumen

Nachdem Sie die Daten wieder hergestellt haben, sollten Sie ihren Server auch wieder aufräumen. Dazu löschen Sie einfach die Postfachdatenbank in der Speichergruppe. Im zweiten Schritt können Sie auch die Speichergruppe entfernen. Allerdings müssen Sie selbst die Dateien entfernen, was ihnen auch der Assistent noch mal gesondert mitteilt:

Dann ist der Platz auf ihrer Festplatte wieder frei gegeben und der Server bereit für die nächste Wiederherstellung.

Grenzen und Risiken

Wenn Sie nun sehr begeistert sind, dann sollten Sie folgende Probleme und Risiken kennen, ehe sie nun alle althergebrachten Sicherungen über den Haufen werfen:

RSG zweckentfremdet

Achtung: Die nun folgende Beschreibung stellt einen Praxisbericht dar aber beschreibt keine von Microsoft oder mir unterstütze Vorgehensweise. Diese Schritte sind bei Problemfällen vielleicht eine mögliche Rettung, wenn alle anderen regulären Versuche erfolglos waren.

Wer das Glück hat, einen Exchange Enterprise Server zu besitzen oder einen zweiten Exchange Server in der Organisation ohne Postfachspeicher betreiben kann, kann mit der Recovery Storage Group auch etwas jonglieren. Zuerst legen Sie wie weiter oben beschrieben eine RSG an und restaurieren ihre Datenbank dort hinein. Um sicher zu stellen, dass dies fehlerfrei ist, können Sie die RSG einmal mounten und dann wieder dismounten. Bis dahin war noch alles bekannt.

Sie haben aber nun nach dem Dismounten auf ihrer Festplatte sowohl eine EDB als auch eine STM-Datei. Es steht nirgends geschrieben, dass diese Dateien sich von einer produktiven Datenbank unterscheiden. Und es ist mit Exchange 2000/2003 auch tatsächlich so, dass Sie eine Datenbank mit einem beliebigen Namen auf einem beliebigen Server einbinden und mounten können, solange nur der Name der Organisation und der Administrativen Gruppe überein stimmt. Während der Name der Organisation bei einer Unstimmigkeit nur schwer zu ändern ist, lässt sich doch sehr schnell eine neue gleich benannte administrative Gruppe anlegen und einen Server dort installieren. Oftmals ist es aber so, dass die Sicherung ihrer Datenbank von einem Server der bestehenden administrativen Gruppe ist.

Sie können daher nun z.B.: auf einem Enterprise Server einfach eine neue Datenbank für Postfächer einrichten und diese einmal kurz starten und wieder beenden. Kopieren Sie dann die EDB/STM-Datei der Recovery Storage Group einfach über die soeben neu angelegte Datenbankdateien. Dann noch schnell "Darf durch Wiederherstellung überschrieben werden" in den Eigenschaften der Datenbank ankreuzen, damit der Store ein ISINTEG durchführt und schon kann die Datenbank bereit gestellt werden.

Was haben Sie nun damit erreicht? Sie haben eine Kopie einer Postfachdatenbank auf ihrem Server als eigenständige Datenbank verfügbar gemacht. Natürlich sind dort nur die Postfächer vom Stand des letzten Backups enthalten und alle Postfächer sind auch mit einem "roten X" gekennzeichnet, denn es gibt ja kein passendes Benutzerkonto im Active Directory. Aber sie können nun ein Benutzerkonto im Active Directory anlegen und eines der Postfächer wieder verbinden und direkt auf dieser Datenbank arbeiten.

Wozu sie das benötigen, werden Sie mich fragen. Nun ja zum einen ist dies natürlich eine wunderbare Möglichkeit die Kopie einer Produktivdatenbank zu erstellen um darauf umfangreiche Tests durchzuführen. Weiterhin kommen Sie über diesen Umweg an Postfächer, die im Active Directory schon gelöscht sind und daher über die normale Funktion der RSG nicht mehr zu erreichen sind (Siehe weiter oben: Grenzen und Risiken). Es passiert auch immer mal wieder, dass in einem Postfach eine Korruption vorliegt, die der Benutzer nicht selbst lösen kann aber beim Export mit EXMERGE oder dem System Manager nicht auffällt. Und letzt können Sie auf so einer Datenbank nun wirklich einen Echttest von ESEUTIL fahren und eine Abschätzung für die Laufzeit im Problemfall erhalten.

Der wichtigste Punkt ist aber, dass Sie über diesen Umweg auch beim Ausfall eines Servers die Datenbank dieses Server z.B.: temporär auf einem anderen Server schon wieder zurückholen können und wenn der alte Server nicht schnell genug wieder repariert werden kann, notfalls sogar auf dem zweiten Server auch produktiv weiter betreiben können. Dazu müssten Sie aber dann bei den Eigenschaften der Benutzer den HomeServer etc. ändern. Ohne ausreichende Kenntnisse dürften Sie dann schneller zu Ziel kommen, indem Sie die Benutzer "Exchange deaktivieren" und dann mit den Mailboxen der wieder hergestellten Datenbank wieder verbinden. Siehe auch MBConn.

Recovery Storage Group und Restore

Wie sie bisher schon gelesen haben, restauriert Exchange eine Bandsicherung immer in die Recovery Storage Group, wenn diese da ist. Nur wenn es keine RSG gibt, wird ein Restore in die produktive Datenbank versucht, bei der dazu aber auch "darf durch Restore überschrieben werden" aktiviert sein muss.

Sollten Sie nun aber dennoch die Anforderung haben, eine Datenbank in eine produktive Datenbank zu restaurieren, müssten Sie normalerweise die Recovery Storage Group löschen und danach wieder anlegen. Dieser Umweg kann durch das Setzen des folgenden Schlüssels vermieden werden.

Pfad:HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\
Key:Recovery SG Override
Typ: DWORD
Wert = 1

Diese Einstellung erlaubt dann die Wiederherstellung in eine bestehende Datenbank trotz vorhandener Recovery Storage Group.

Achtung:
Wenn sie nun aber wieder in die RSG restaurieren wollen, müssen Sie den Key wieder löschen oder auf "0" setzen. Wenn Sie dies nicht machen, dann versucht Exchange wieder die produktive Datenbank zu überschreiben.

Weitere Links

Keywords:Recoverystoragegroup RSG Notfall Wiederherstellung