Backup und Restore bei Exchange Server 2003

04.10.2006 von William Boswell
Die Sicherung der Daten auf einem Exchange Server gehört zu den elementaren Pflichten eines Administrators. Unsere Serie zu Exchange Server 2003 zeigt im dritten Teil, welche Möglichkeiten Sie dabei haben - und wie Sie die Daten im Notfall auch wieder restaurieren.

In den ersten beiden Teilen unserer Serie zur Administration von Exchange Server 2003 haben wird den Schutz der User vor Spam und Viren erläutert. Doch auch die Postfächer der Benutzer und der Server selbst müssen geschützt werden. Selbst ohne einen Angriff lauern für die gespeicherten Daten viele Gefahren.

Sei es menschliches Versagen des Anwenders oder des Administrators, sei es ein Hardwaredefekt im RAID-Array oder auf dem Mainboard des Servers: Wenn die Anwender keinen Zugriff mehr auf ihre Postfächer haben, gerät der Exchange-Administrator in Stress.

Dann erst zeigt sich, ob das Backup-Konzept auch ausgereift war. Im Folgenden zeigen wir Ihnen verschiedene Szenarien für mögliche Problemfälle und was nötig ist, damit daraus keine Katastrophen werden.

Unsere neue Serie zu Exchange Server 2003 basiert auf Kapitel 13 des Standardwerks „Exchange Server 2003“ von William Boswell aus dem Verlag Addison-Wesley. Sie können dieses über 850 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.

Inhalt der Artikelserie zur Exchange-Sicherheit

Teil 1: Spam und Virenabwehr durch Blockierlisten

Teil 2: Spam und Virenabwehr durch Challenge-Response und Filter

Teil 3: Backup und Restore bei Exchange Server 2003

Teil 4: Backup von Exchange Server 2003 in der Praxis

Teil 5: Exchange Server 2003 mit Schattenkopien nutzen

Teil 6: Höhere Diensteverfügbarkeit durch Exchange-Cluster, I

Teil 7: Höhere Diensteverfügbarkeit durch Exchange-Cluster, II

Teil 8: Höhere Diensteverfügbarkeit durch Exchange-Cluster, III

Einsatz von Sicherungsbändern

In folgenden Situationen müssen Sie eventuell auf Sicherungsbänder zurückgreifen:

Hinweis: Meine Beispiele in diesem Kapitel beschränken sich auf die Verwendung von Sicherungsbändern. Sie sind am Arbeitsplatz die einfachste Lösung. Etliche Organisationen speichern ihre Sicherungskopien jedoch bereits auf Platten – entweder als Teil einer gemischten Lösung, in der die Platten zusammen mit Bändern verwendet werden, oder in Folge einer veränderten Strategie, die ganz von der Verwendung von Bändern abkommt. Ehe Sie für Ihre Produktionsumgebung Hardware für die Bandsicherung kaufen, möchte ich Sie ermutigen, sich mit plattenbasierten Lösungen zu beschäftigen. Sie werden feststellen, dass sie gar nicht so teuer sind.

Dienste, auf die Exchange angewiesen ist

Denken Sie daran, dass es nicht nur Ereignisse gibt, die einen Exchange-Server direkt betreffen, sondern dass Exchange auch auf Dienste auf anderen Servern angewiesen ist:

Zu jeder Wiederherstellungsstrategie für Exchange gehören zwingend pannensichere Prozesse für die Sicherung und Wiederherstellung dieser Dienste, entweder mit Hilfe einer Bandsicherung oder mit zusätzlichen Servern.

Ehe wir den nächsten Punkt ansprechen, noch eine letzte Überlegung. Auch wenn das vielleicht moralisierend klingt, möchte ich Sie daran erinnern (bzw. Sie erinnern, dass Sie Ihren Chef erinnern), darauf zu achten, dass Sie Ihre Wiederherstellungsverfahren nicht erst dann zum ersten Mal testen, wenn die Katastrophe eingetreten ist. Planen Sie Ihr Vorgehen und üben Sie es in Ihrem Büro. Ich war früher in einem Atom-U-Boot für den Reaktor zuständig. Glauben Sie mir, ich habe genau wie alle anderen über den endlosen Drill und die langweiligen Einsatzberichte gemeckert. Aber wenn „sich die Steuerstäbe senken, das Wasser kommt und die Lichter ausgehen“, wie man dort sagt, dann ist es tröstlich zu wissen, dass es Verfahren zur Wiederherstellung gibt, die bei richtiger Anwendung auch funktionieren.

Tipp: Wenn ein Element in einem Postfach oder ein Benutzerkonto im Active Directory versehentlich gelöscht wurde müssen Sie nicht unbedingt auf Ihre Sicherungsbänder zurückgreifen. Der Informationsspeicher bewahrt gelöschte Elemente standardmäßig sieben Tage auf und gelöschte Postfächer dreißig Tage. Diese Einstellungen können Sie noch problemlos erhöhen, ohne zu viel zusätzlichen Speicher zu belegen.

Konsistenzprüfung

Der Informationsspeicherdienst enthält eine Backup-API mit Funktionen, mit denen Sie auf verfügbare Postfächer und Informationsspeicher für öffentliche Ordner zugreifen können. Diese API wird von Ntbackup unter Windows Server 2003 und von nahezu allen Backupanwendungen anderer Anbieter genutzt, was aber nicht heißt, dass alle solchen Anwendungen für Exchange nach demselben System vorgehen. Die API stellt einfach nur eine Reihe von Werkzeugen zur Verfügung, die alle Hersteller auf unterschiedliche Weise nutzen.

Wenn der Informationsspeicher während eines Backups weiterhin zur Verfügung steht, dann kann die Backup-API auch auf das Transaktionsprotokoll zugreifen. Auf diese Weise wird sichergestellt, dass alle Elemente in den zentralen Datenbankdateien beendet und alle Protokolldateien abgeschnitten (gelöscht) werden, die nach dem Abschluss der Backups nicht mehr benötigt werden. Ein weiterer Vorteil besteht darin, dass Sie bei der Übertragung der Seiten auf das Bandlaufwerk die Konsistenz der Datenbank überprüfen können.

Onlineanalyse der Datenbankintegrität

In der EDB-Datenbank im Speicher von Exchange sind die Daten in Form von Seiten abgelegt. Jede Seite ist 4 Kbyte groß. Wenn der Informationsspeicherdienst eine Seite in der Datenbank ablegt, berechnet er gleichzeitig eine Prüfsumme ihrer Inhalte und speichert diese zusammen mit der Seite ab. Sobald die Backup-API auf eine Seite zugreift, erstellt der Informationsspeicher für sie ebenfalls eine Prüfsumme und vergleicht diese mit dem gespeicherten Wert. Falls die Ergebnisse nicht übereinstimmen, holt der Speicher die Seite ein zweites Mal und wiederholt die Berechnung der Prüfsumme. Stimmen die Ergebnisse auch dann nicht, bricht der Informationsspeicherdienst das Backup ab, indem er einen bestimmten Fehlercode an die API schickt. Der Ursprung des Fehlers wird im Ereignisprotokoll gespeichert, eventuell auch im Backupprotokoll.

Zu den typischen Ursachen von Prüfsummenfehlern während der Sicherung und Wiederherstellung gehören fehlerhafte SCSI-Anschlüsse und Abschlusswiderstände, fehlerhafte SCSI-Laufwerke oder Bandgeräte, schlecht geschriebene oder inkompatible Gerätetreiber für SCSI-, RAID- bzw. Bandgeräte oder Fehler in der Zeitabstimmung. Wenn Sie im Ereignisprotokoll Prüfsummenfehler oder den Fehlercode -1018 sehen, gehen Sie das Problem sofort an. Denken Sie dabei daran, dass solche Fehler auf die Hardware zurückzuführen sind, nicht auf inkompatible Anwendungen.

Dateibasierte Sicherung

Da die Backup-API zusätzlich Daten verarbeitet, ist der Zeitbedarf für Sicherung und Wiederherstellung bei Exchange-Datenbankdateien wesentlich höher als bei der Sicherung von Datendateien vergleichbarer Größe. Wenn dieser zusätzliche Zeitaufwand in Ihrer Organisation nicht akzeptabel ist, können Sie Ihre Sicherung auch in zwei Schritten durchführen:

Falls die Speicherdateien beschädigt werden sollten, können Sie sie rasch durch eine Kopie der Backupdateien ersetzen und die Datenbank einrichten.

Während eines Offlinebackups stehen den Benutzern keine E-Mail-Funktionen zur Verfügung. Bei der Wiederherstellung eines Offlinebackups können Sie die Inhalte nicht mit Transaktionsprotokollen ergänzen, aber dafür läuft der Vorgang sehr schnell ab. Wenn das für Sie wichtig ist, sollten Sie sich jedoch auch einmal mit den Lösungen von Exchange 2003 für die Wiederherstellung beschäftigen, die Snapshots nutzen und weiter hinten in diesem Artikel besprochen werden.

Offlineanalyse mit Hilfe von Isinteg

Wenn ein Konsistenzfehler auftritt, können Sie mit dem Hilfsprogramm Isinteg eine ausführlichere Analyse des Problems erhalten. Führen Sie Tests mit Isinteg immer im schreibgeschützten Modus durch. Sollten Sie der Meinung sein, dass ein Fehler mit einer Korrektur behoben werden muss, dann empfehle ich Ihnen, sich Hilfe bei den Microsoft Product Support Services zu holen. Wenn Sie vergleichen, was der Rat eines Fachmanns wert ist, der so etwas jeden Tag macht und sich für Sie so viel Zeit nimmt, wie Sie brauchen, dann ist das Gespräch nicht teuer.

Das folgende Listing ist ein Beispiel für einen Test mit Isinteg. Ehe er durchgeführt werden kann, muss die Bereitstellung der Datenbank aufgehoben sein. Die ersten beiden Zeilen umfassen eine einzige Befehlszeichenfolge.

D:\Programmexchsrvr\MDBDATA>isinteg -s server1 -verbose -l log.txt -test folder,message,aclitem,mailbox,dumpsterprops
Databases for server server1:
Only databases marked as Offline can be checked
Index Status Database-Name
Storage Group Name: First Storage Group
1 Offline Mailbox Store (SERVER1)
2 Online MS2 - SG1
3 Online Public Folder Store (SERVER1)
Enter a number to select a database or press Return to exit.
1
You have selected First Storage Group / Mailbox Store (SERVER1).
Continue?(Y/N)y
Test reference table construction result: 0 error(s); 0 warning(s); 0 fix(es); 0 row(s); time: 0h:0m:0s
Test Folder result: 0 error(s); 0 warning(s); 0 fix(es); 183 row(s); time: 0h:0m:0s
Test Deleted Messages result: 0 error(s); 0 warning(s); 0 fix(es); 0 row(s); time: 0h:0m:0s
Test Message result: 0 error(s); 0 warning(s); 0 fix(es); 445 row(s); time: 0h:0m:0s
Test Attachment result: 0 error(s); 0 warning(s); 0 fix(es); 448 row(s); time: 0h:0m:0s
Test Mailbox result: 0 error(s); 0 warning(s); 0 fix(es); 9 row(s); time: 0h:0m:0s
Test reference count verification result: 0 error(s); 0 warning(s); 0 fix(es); 0 row(s); time: 0h:0m:0s
Now in test 8(Row Count/Dumpster Count) of total 8 tests; 100% complete.

Sicherungen und Transaktionsprotokolle

Die Arbeitsweise der Backup-API ist unterschiedlich, je nachdem, welche Art von Sicherung Sie durchführen.

Vollständige Sicherung

Nach Abschluss einer vollständigen Sicherung löscht die Backup-API die Transaktionsprotokolle mit Ausnahme der Hauptdatei E00.log und der Protokolldatei mit der höchsten Ziffer, die beide als Platzhalter dienen.

Eine vollständige Sicherung braucht möglicherweise viel Zeit. Wenn Sie in einer Speichergruppe mehrere Postfachspeicher mit 40 Gbyte und einen Informationsspeicher für öffentliche Ordner mit 30 Gbyte haben, dann kann eine vollständige Sicherung der gesamten Speichergruppe mehrere Stunden dauern. (Bei Exchange Standard Edition gibt es nur einen Postfachspeicher und einen Informationsspeicher für öffentliche Ordner mit jeweils 16 Gbyte. Daher ist der Zeitbedarf für die Sicherung begrenzt und wird eher von der Geschwindigkeit des Bandlaufwerks und des Netzwerks bestimmt.)

Achtung: Ntbackup führt mit der Einstellung „Normal“ eine vollständige Sicherung durch.

Inkrementelle und differenzielle Sicherung

Bei einer inkrementellen Sicherung werden nur die Transaktionsprotokolle gespeichert, nicht die Hauptdateien der Datenbank. So lässt sich eine Sicherung in der Nacht sehr rasch durchführen.

Folgende Abbildung zeigt das Verwaltungsfenster von Ntbackup mit drei Gruppen von Backupdateien. In der ersten Gruppe wurde eine vollständige (normale) Sicherung des Postfachspeichers, des Informationsspeichers für öffentliche Ordner und der Transaktionsprotokolle für die Speichergruppe EX1-SG1 durchgeführt. Die anderen beiden Gruppen inkrementeller Sicherungen umfassen nur die Transaktionsprotokolle der jeweiligen Speichergruppe auf.

Nach einer inkrementellen Sicherung löscht die API die Transaktionsprotokolle mit Ausnahme von E00.log und der Protokolldatei mit der höchsten Zahl als Platzhalter. Das bedeutet, dass Sie für eine Wiederherstellung von Daten das Band mit der letzten vollständigen Sicherung und die Bänder mit der inkrementellen Sicherung von jeder Nacht brauchen. Dadurch wird die Wiederherstellung komplizierter und die Gefahr größer, dass der Vorgang infolge eines Bandfehlers abbricht. (Natürlich speichert nicht jeder Sicherungskopien auf Bänder. Aber auch in diesem Fall besteht die Gefahr, dass ein Medium ausfällt und die Wiederherstellung schwierig wird.)

Eine differenzielle Sicherung erfasst zwar auch nur die Transaktionsprotokolle, löscht aber die alten Protokolle nicht. Das hat zur Folge, dass jede Sicherung länger dauert als ihre Vorgänger, Sie für die Wiederherstellung von Daten aber nur die Bänder von der letzten vollständigen und der letzten differenziellen Sicherung brauchen.

Auswahl des Sicherungstyps

Wenn es um eine möglichst schnelle und einfache Wiederherstellung geht, ist eine vollständige Sicherung jede Nacht der klare Favorit. Diese Schnelligkeit und Einfachheit haben jedoch auch ihre Nachteile:

Längere Backups: Die Sicherung dauert sehr viel länger. Für Benutzer, die während der Sicherung E-Mails lesen möchten und dabei Leistungseinbußen hinnehmen müssen, kann das lästig und frustrierend sein.

Längere Belegung der Bandlaufwerke: Möglicherweise hat der Backupserver neben den Exchange-Backups noch andere Aufgaben. Wenn Sie den Verantwortlichen nicht davon überzeugen können, dass Sie für ein paar Stunden zwei oder drei Laufwerke brauchen, reicht Ihnen möglicherweise die Zeit für eine Sicherung nicht aus.

Mögliche Wartungskonflikte: Jede Nacht führt der Informationsspeicher eine Onlinewartung durch, damit die Datenbanken kompakt und fehlerfrei bleiben. Wenn für irgendeinen Speicher in einer Speichergruppe die Sicherung anläuft, dann wird die Wartung für alle Speicher in dieser Gruppe unterbrochen. Kontrollieren Sie Ihre Ereignisprotokolle, ob Wartungsfehler auftreten, und planen Sie die Sicherung entsprechend.

Wenn eine vollständige Sicherung jede Nacht nicht möglich ist, greifen Sie auf unterschiedliche Sicherungen zurück. Läuft über Ihren Exchange-Server so viel Verkehr, dass der wöchentliche Zuwachs an Transaktionsprotokollen das Laufwerk mit den Protokolldateien überfordert, dann führen Sie inkrementelle Backups durch und lassen die Bänder mit den nächtlichen Sicherungen griffbereit liegen, damit im Ernstfall eine schnelle Wiederherstellung möglich ist.

Überblick über Sicherung und Wiederherstellung

Ehe wir uns Schritt für Schritt den Ablauf für die Sicherung und Wiederherstellung eines Exchange-Servers ansehen, sollten Sie einige der beteiligten Prozesse kennen. So können Sie sich besser vorstellen, was während der nächtlichen Backups abläuft, und Ihre Verfahren für die Wiederherstellung einfacher gestalten.

Sehen wir uns zunächst einmal an, welche Exchange-Dateien an einer Sicherung beteiligt sind. Das Diagramm in obiger Abbildung zeigt Beispiele von Dateipfaden für einen Exchange-Server mit Enterprise Edition. Auf dem Server gibt es nur eine Speichergruppe mit zwei Postfachspeichern und dem Standardinformationsspeicher für öffentliche Ordner.

Fehlertoleranz und Speicherorte

Die zentralen Datenbankdateien für jeden Speicher, die EDB- und die STM-Datei, sind auf einem eigenen RAID-Array gespeichert. Der Speicherort der Dateien hat keinen Einfluss auf das Backupprogramm, aber wenn ein Array ausfällt und Sie überprüfen müssen, wie weit die Sicherung durchgeführt wurde, ist dieser Punkt wichtig.

Wenn Ihnen die Vereinbarungen mit Ihren Vorgesetzten und Benutzern (formell oder informell) Spielraum lassen, können Sie Kosten sparen, indem Sie mehrere Postfachspeicher auf demselben RAID-Array unterbringen. Nur sollten Sie Speicher aus unterschiedlichen Speichergruppen nicht auf einem Array vermischen, da dann die Wiederherstellung komplizierter ist.

Alle Veränderungen an Speichern in einer Speichergruppe werden zuerst in mehreren Transaktionsprotokollen abgelegt. Für diese Speichergruppe ist E00.log das wichtigste Transaktionsprotokoll. Sobald es voll ist, ändert der Informationsspeicherdienst den Namen der Datei zur nächsthöheren Ziffer und legt eine neue Datei mit der Bezeichnung E00.log an.

Vermeidung von Schwachstellen

Die Transaktionsprotokolle sind auf einem eigenen RAID-Array abgespeichert, um die Leistungsfähigkeit und die Möglichkeiten zur Wiederherstellung zu verbessern. Es müssten mehrere Fehler zusammen auftreten, um beide Arrays mit den Datendateien und den Transaktionsprotokollen gleichzeitig ausfallen zu lassen. Ich sage nicht, dass das nicht vorkommen kann. Aber Sicherung gegen Katastrophen ist wie Black Jack. Da ist es wichtig, im Vorteil zu sein, und Sie erhöhen Ihren Vorteil, wenn Sie die Datendateien und die Transaktionsprotokolle auf unterschiedlichen Arrays speichern.

Wenn möglich, vermeiden Sie kritische Schwachpunkte. Wenn Sie z.B. unterschiedliche RAID-Arrays verwenden, aber für alle nur einen RAID-Controller einsetzen, fordern Sie Murphy geradezu heraus.

Bei einer Multithread-Sicherungsanwendung, die ein Bandgerät mit mehreren Laufwerken nutzt, können Sie die Speicher einer Speichergruppe nur nacheinander sichern. Auch die Reihenfolge der Backups können Sie nicht steuern. Sie können nicht sagen: „Sichere diese beiden Speicher zuerst, weil sie am wichtigsten sind.“ Wenn Sie den zeitlichen Ablauf der Sicherungen genau steuern möchten, müssen Sie weitere Speichergruppen erstellen und die Speicher dort ablegen.

Hinweis: Wenn Sie ein Händler sind, dessen Kunden Kleinunternehmen sind und bei jeder neu installierten Komponente über die Kosten jammern, dann werden Sie Exchange Enterprise Edition wahrscheinlich nicht verwenden. Also können Sie das Risiko auch nicht auf mehrere Speichergruppen verteilen. Aber auch dann sollten Sie darauf bestehen, dass die Protokolle und Datendateien auf unterschiedlichen Arrays abgelegt werden, selbst wenn die Arrays auf gespiegelten ATA-Laufwerken liegen. Nur so können Sie die Möglichkeiten für die Wiederherstellung und verbesserte Leistungsfähigkeit nutzen.

Abfolge der Sicherungen

Stellen Sie sich vor, es ist Sonntagnachmittag und Sie beginnen eine vollständige Sicherung der Dateien auf dem Exchange-Server, die in vorhergehender Abbildung dargestellt sind. Die Sicherung umfasst die Hauptdatenbankdateien und die Transaktionsprotokolle E00000014.log bis E00000017.log. Da es sich um eine vollständige Sicherung handelt, löscht die Backup-API alle Protokolle bis auf E00.log und E00000017.log.

Dann läuft der Server einen Tag lang, empfängt und verschickt neue E-Mails und ist überhaupt ein guter Exchange-Server. Am Montag Abend kurz vor der Sicherung sieht der Ordner mit den Transaktionsprotokollen so aus wie im folgenden Diagramm.

Über den Tag hinweg hat der Informationsspeicher der Datenbank neue Elemente hinzugefügt und deshalb mehrere neue Transaktionsprotokolle angelegt. Alle Elemente in diesen Protokollen sind schon lange in den Hauptdatenbankdateien festgeschrieben. Nur für den Notfall enthält die Prüfpunktdatei E00.chk einen Zeiger auf den Speicherort von Elementen, die noch nicht festgeschrieben sind.

Jetzt führen Sie eine inkrementelle Sicherung durch. Dabei werden alle noch ausstehenden Elemente in den Hauptdatenbankdateien festgeschrieben und alle alten Transaktionsprotokolle außer E00000020.log gelöscht.

In der folgenden Nacht, am Dienstag, führen Sie eine weitere inkrementelle Sicherung mit den Transaktionsprotokollen dieses Tages durch, E00000020.log bis E00000023.log. Am Mittwoch umfasst die Sicherung E00000023.log bis E00000026.log.

Tipp: Die Bänder mit den täglichen inkrementellen Sicherungen von Exchange sollen Sie nicht auslagern. Es ist ziemlich peinlich, wenn Sie mit einer Wiederherstellung warten müssen, bis ein Verantwortlicher des betreffenden Unternehmens Ihre Bänder in seinem Archiv gefunden und per Kurier an Sie zurückgeschickt hat.

Fehlermeldung

Nun haben wir den fünften Tag nach der vollständigen Sicherung. Eine Benutzerin meldet dem Helpdesk, dass sie keine neuen E-Mails empfangen kann. Wenn sie versucht, Nachrichten abzurufen oder zu verschicken, öffnet sich unten abgebildetes Fenster und meldet, dass der Server nicht verfügbar ist. „In der Meldung steht, ich soll mich an meinen Administrator wenden. Das sind doch Sie, oder?“, fragt sie den Techniker vom Helpdesk. (Hoffentlich gibt es in Ihrer Produktionsumgebung ein Überwachungssystem, das Sie auf ein Problem hinweist, bevor es die Benutzer tun.)

Der Techniker erstellt eine Störungsmeldung und ruft Sie in aller Eile an. Sie öffnen ESM und stellen fest, dass der Postfachspeicher nicht mehr zur Verfügung steht und im Anwendungsprotokoll unzählige Nachrichten von MSExchangeIS ein Klagelied über fehlerhafte Meldungen, einen nicht lesbaren Informationsspeicher und andere Hiobsbotschaften anstimmen.

Sie stellen fest, dass der Postfachspeicher beschädigt ist, und beschließen, ihn mit der letzten fehlerfreien Sicherungskopie wiederherzustellen. Also holen Sie die Bänder und bereiten eine Wiederherstellung des Speichers vor. Dazu nutzen Sie die Verfahren, die wir später in diesem Artikel besprechen.

Wiederherstellung vom Band

Ehe Sie mit der Wiederherstellung beginnen, sollten Sie Kopien der Datenbankdateien an einem anderen Ort speichern. Dadurch stellen Sie sicher, dass der Status quo auf dem Server gesichert ist, falls die Wiederherstellung fehlschlägt und Sie an der Datenbank eine Operation vornehmen müssen.

Und jetzt wird das Leben für Sie interessant. Sie haben jede Nacht eine inkrementelle Sicherung durchgeführt, also brauchen Sie ganz viele Bänder: Die vollständige Sicherung vom Sonntag und alle Bänder der inkrementellen Sicherungen von Montag bis Mittwoch.

Außerdem brauchen Sie die aktuellen Transaktionsprotokolle auf der Festplatte, denn dort sind die Elemente abgelegt, die seit der Sicherung vom Mittwoch in den Speichern der Speichergruppe festgeschrieben wurden. Diese Dateien sind in folgender Abbildung dargestellt.

Sie nehmen den Postfachspeicher außer Betrieb und stellen die Dateien eine nach der anderen vom Band wieder her. Da der Speicher beschädigt ist, richten Sie das Sicherungsprogramm so ein, dass es die bestehenden Datenbankdateien des Postfachs, priv1.edb und pub1.edb, ersetzt.

Wenn Sie die vollständige Sicherung vom Sonntag wiederherstellen, überschreibt das Programm die Dateien auf der Festplatte mit denen vom Band. Dann legt es einen kleinen Ordner für temporäre Dateien an und speichert dort die Transaktionsprotokolle vom Band. Anschließend erstellt die Backup-API eine Datei Restore.env, die verfolgt, welche Dateien Sie vom Band wiederherstellen.

Als Nächstes kommt das Band mit der inkrementellen Sicherung vom Montag. Dort sind nur Transaktionsprotokolle gespeichert. Sie richten das Sicherungsprogramm so ein, dass es die Protokolle im bereits vorhandenen temporären Ordner speichert. Für das Band vom Dienstag führen Sie diesen Vorgang ebenfalls durch. Beim letzten Band vom Mittwoch müssen Sie jedoch etwas anders vorgehen.

Durchführen der endgültigen Wiederherstellung

Wenn Sie das Band vom Mittwoch wiederherstellen, müssen Sie im Sicherungsprogramm ein Flag setzen und damit anzeigen, dass dies das letzte Band für die Wiederherstellung ist. Wie Sie gleich in der Schrittanleitung sehen werden, wird dieses Flag in ESM als eine der Eigenschaften für den Postfachspeicher angezeigt.

  1. Wenn Ntbackup die letzten Protokolldateien von diesem Band wiederhergestellt hat, gibt es der Backup-API die Anweisung, eine so genannte dauerhafte Wiederherstellung durchzuführen. Dafür greift die API auf den Inhalt von Restore.env zurück und überträgt dann die Inhalte der Transaktionsprotokolle aus dem temporären Ordner wieder in die Hauptdatenbankdateien.

  2. Die Backup-API schreibt zunächst die Elemente der alten Transaktionsprotokolle fest und anschließend die Inhalte der aktuellen Protokolle, in unserem Beispiel E00000026.log bis E00000029.log. Dadurch sind die Hauptdatenbankdateien wieder auf dem Stand vor der Stilllegung des Postfachservers.

  3. Anschließend weist das Sicherungsprogramm den Informationsspeicher an, den Postfachspeicher wieder in Betrieb zu nehmen. Diesen Vorgang können Sie auch manuell durchführen. Zu diesem Zeitpunkt werden alle Nachrichten zugestellt, die zwischenzeitlich eingegangen sind und in SMTP in der Warteschlange stecken.

  4. Das Endergebnis? Die Benutzer bekommen alle ihre Nachrichten zurück und waren nur insofern eingeschränkt, dass sie nicht auf ihre E-Mails zugreifen konnten, während der Mailserver nicht zur Verfügung stand. Die übrigen Speicher in der Speichergruppe waren nicht betroffen.

Wenn Sie darauf achten, dass die Dateien im Postfachspeicher möglichst klein bleiben, und eine differenzielle Sicherung verwenden, die alle Transaktionsprotokolle seit der letzten vollständigen Sicherung erhält, dann können Sie den Zeitaufwand für diesen Vorgang minimieren.

Zusammenfassung des Ablaufs

Hier sind nochmals die wichtigsten Punkte im Zusammenhang mit Onlinesicherung und Wiederherstellung zusammengefasst:

Sicherung einzelner Postfächer

Sicherungs- und Wiederherstellungsvorgänge mit der Backup-API schlucken einen Speicher auf einmal, wie eine Schlange, die einen Elefanten verschlingt. Die Benutzer dagegen sehen einen Postfachspeicher nicht als einen Strom von Seiten an, sondern als eine Gruppe von Postfächern, genauer gesagt ihres eigenen Postfachs, das natürlich das wichtigste auf dem ganzen Server ist.

Ein einziges Postfach mit der Backup-API vom Band wiederherzustellen, ist nicht so einfach, wie Sie das gerne hätten. Sie müssen zuerst den gesamten Postfachspeicher in einem temporären Speicherort wiederherstellen, der so genannten Speichergruppe für die Wiederherstellung. Dann legen Sie die Inhalte des Postfachs mit Hilfe von Exmerge in einer PST-Datei ab, importieren diese in das Postfach des Benutzers und führen die Inhalte zusammen, damit die Nachrichten, die erst nach der Meldung des Fehlers eingegangen sind, nicht überschrieben werden.

Für andere Methoden, ein Postfach wiederherzustellen, gibt es bei Microsoft keine direkte Unterstützung. Aber viele Hersteller von Backupprogrammen bieten Lösungen an, mit denen sich einzelne Postfächer über eine MAPI-Verbindung sichern und wiederherstellen lassen.

Mit diesem Verfahren können Sie ein einzelnes Postfach direkt vom Band wiederherstellen und müssen sich nicht die Mühe machen, in der Speichergruppe für die Wiederherstellung den gesamten Postfachspeicher zu rekonstruieren.

Nachteile

Im Universum gibt es ein unveränderliches Gesetz, das besagt: „Bequemlichkeit hat ihren Preis, und die Höhe dieses Preises ist direkt proportional zur Größe der Bequemlichkeit.“ Die Sicherung einzelner Postfächer ist sehr bequem, deshalb sollte es Sie mit diesem Gesetz im Hinterkopf nicht überraschen, dass sie auch sehr teuer ist, zumindest was die Verarbeitungslast, die Plattenbelastung, die benötigte Bandbreite im Netzwerk und die Kilometer an verbrauchtem Speicherband angeht.

Im Grunde ist eine Sicherung einzelner Postfächer gleichbedeutend mit einer Aufforderung an alle Benutzer eines Postfachspeichers, ihre Postfächer zu öffnen und alle Nachrichten und Kalenderelemente in allen Ordnern zu lesen. Dieser Vorgang ist nicht nur ausgesprochen aufwändig, er ist auch langsam. Sehr langsam. Wenn die vollständige Sicherung eines Postfachspeichers mit der Backup-API normalerweise drei Stunden dauert, dann kann die Sicherung einzelner Postfächer je nach deren Größe neun Stunden und mehr benötigen.

Dennoch ist es gut, wenn Sie wissen, dass es diese Möglichkeit gibt. In einigen Organisationen gibt es eine einzelne Sicherung für die wichtigsten Postfächer, wobei „wichtig“ dort definiert wird als „der Besitzer überwacht das Budget für die Informationstechnologie“. In anderen Organisationen können Benutzer einen begründeten Antrag auf Wiederherstellung ihres Postfachs stellen.

Die Situation stellt sich positiver dar, wenn Exchange 2003 unter Windows Server 2003 läuft. Wenn Sie eine Sicherungssoftware verwenden, die Volumeschattenkopien unterstützt (dieser Dienst wird im nächsten Teil unserer Artikelserie vorgestellt), dann erstellen Sie Schnappschüsse des Postfachspeichers in Echtzeit und damit ein Bild eines einzelnen Postfachs. Daraus lassen sich anschließend einzelne oder alle Elemente wiederherstellen. Sie können auch eine reguläre Sicherung durchführen und dann ein Hilfsprogramm eines anderen Herstellers verwenden, das einzelne Objekte aus einer nicht bereitgestellten Exchange-Datenbank abrufen kann, z.B. Ontrack PowerControls. Weitere Informationen finden Sie unter http://www.ontrack.com/powercontrols.

Ausblick

In diesem Teil haben wir die Grundlagen der Datensicherung von Exchange Server 2003 besprochen. Im nächsten Teil beschäftigen wir uns praxisnah mit den konkreten Abläufen beim Restore ganzer Server oder einzelner Postfächer. (ala)

Unsere neue Serie zu Exchange Server 2003 basiert auf Kapitel 13 des Standardwerks „Exchange Server 2003“ von William Boswell aus dem Verlag Addison-Wesley. Sie können dieses über 850 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.

Inhalt der Artikelserie zur Exchange-Sicherheit

Teil 1: Spam und Virenabwehr durch Blockierlisten

Teil 2: Spam und Virenabwehr durch Challenge-Response und Filter

Teil 3: Backup und Restore bei Exchange Server 2003

Teil 4: Backup von Exchange Server 2003 in der Praxis

Teil 5: Exchange Server 2003 mit Schattenkopien nutzen

Teil 6: Höhere Diensteverfügbarkeit durch Exchange-Cluster, I

Teil 7: Höhere Diensteverfügbarkeit durch Exchange-Cluster, II

Teil 8: Höhere Diensteverfügbarkeit durch Exchange-Cluster, III