Exchange Backup und Restore - Voraussetzungen

.. für ein erfolgreiches Backup

Um eine komplette Sicherung des Server zu haben, müssen Sie folgende Bereiche sichern:

  • Dateisystem
    Sie sollten alle lokalen Dateisysteme (C:, D:, E: etc.) sichern, damit Sie im Falle eines Defektes auch die Programme auf dem Server wieder restaurieren können.
    Das Laufwerk M: dürfen sie aber NICHT sichern !!! (Siehe auch Laufwerk M:)
    Ebenso werden Sie mit einem Dateibackup einige Dateien nicht sichern können, die permanent offen sind. Diese werden über spezielle Schnittstellen gesichert. Um die Anzahl der späteren Fehlermeldungen zu reduzieren, können wir die gesperrten Dateien (WINS, DHCP, TEMP-Verzeichnis, und alles in MDBDATA) aus dem Backup ausschließen.
    Dies ist ab Windows 2003 bei einer Sicherung über Schattenkopien nicht mehr erforderlich.
  • Windows 2000 Systemstatus
    Damit wird das Betriebssystem, die SAM, die Registrierung, COM-Objekte und alles weitere gesichert, die nicht über ein Dateibackup von C: gesichert werden können.
  • Exchange Informationsspeicher
    Hiermit sichern wir "online" den Exchange Speicher.
    Dies können durchaus mehrere Speichergruppen und Datenbanken sein als auch Zusatzdienste wie der SRS.
  • Sicherung der Mailboxen
    Dies ist nur eine optionale zusätzliche Sicherung, wobei eine Sicherung der Mailboxinhalt kein Backup ist, sondern eher ein Export. Siehe auch Backup
  • Active Directory
    Da im Active Directory Exchange die Konfiguration und die Benutzerdaten ablegt, benötigen Sie auch hiervon ein Backup. Beachten Sie dabei

    Die "EINZIGE" legitime Wiederherstellung eines DCs ist ein restore des "SystemState"

    Eine Wiederherstellung z.B. per Imaging etc. ist nicht ratsam. Siehe dazu auch 875495 How to detect and recover from a USN rollback in Windows Server 2003 und 885875 How to detect and recover from a USN rollback in Windows 2000 Server

Ist doch alles ganz einfach. Trotzdem wünsche ihnen täglich ein erfolgreiches Backup, welches sie auch regelmäßig kontrollieren sollten. Am Beispiel mit Backup Exec habe ich ihnen auf einer eigenen Seite aufgezeigt, wie ein richtiges Backup aussehen sollte. Weiterhin sollten sie ab uns an einen Restore auf einem Testsystem verifizieren.

Sie können auch teilweise die Funktion prüfen, in dem Sie eine Wiederherstellung von Teilen des Dateisystems in ein temporäres Verzeichnis umleiten. Denn auch ein Bandlaufwerk und ein Band "altert" und Bedarf der Kontrolle.

Zuallerletzt sollten sie auch eine Rotation für die Bänder überlegen. Es bietet sich immer an, auch dem Server ein besonderes "Weihnachtsgeschenk" zu machen. Wechseln Sie ihre Bänder regelmäßig weil auch diese dem Verschleiß unterliegen. Einige Backupprogramme (z.B. BackupExec) liefern ihnen genaue Bandberichte, die eine Aussage über die Zuverlässigkeit des Bandes machen. Nicht wundern, denn Sie werden nach einigen Durchläufen immer "behebbare Fehler" haben. Dafür haben Bandlaufwerke umfangreiche Sicherungstechniken mit Prüfsummen (CRC). Allerdings sind irgendwann auch diese Reserven aufgebraucht. Je nach Bandtechnik ist ein Band nach 10-20 Durchläufen (z.B. DAT) schon nicht mehr vertrauenswürdig.

.. für ein erfolgreiches Restore

Allein das Backup eines Exchange Servers ist noch keine Garantie für ein erfolgreiches Restore. Ehe wir und daher um die einzelnen Wege eines Backups kümmern, sollten sie folgende Voraussetzungen können, damit ihr Backup und Restore überhaupt funktionieren kann.

Diese Voraussetzungen sind Pflicht um eine Datenbank wieder starten zu können, damit Sie überhaupt wieder an die Daten herankommen, z.B. Um diese zu extrahieren. Weitere Punkte müssen stimme, um ein komplettes funktionsfähiges Restore eines Servers zu erreichen. Ohne die Verzeichnisdatenbank kommen Sie zwar trotzdem mit einigen Tricks an Ordner und Postfächer, aber nicht ihre Anwender. D.h. nur wenn sie auch die Verzeichnisdatenbank und die Windows Einstellungen (Registrierung) mit den Connectoren und Diensten gesichert haben, erhalten sie bei ihrem Restore auch einen funktionierenden Server. Ansonsten erhalten Sie eine laufende Datenbank, deren Inhalte in einen neuen Server übernommen werden können oder mit viel manueller Nachkonfiguration ein Server werden kann.

Exchange 5.5

Exchange 5.5. ist sehr streng, was die Voraussetzungen betrifft. Zum einen verhindert dies, dass jemand eine Datenbank "einfach mal " woanders restauriert, zum anderen verhindert dies ein falsches Restore auf den falschen Server.

  • Der Name der Organisation muss gleich sein
    Hier zählt nicht der "Displayname", sondern der interne Name, welcher bei der Installation eingegeben (und hoffentlich dokumentiert ) wurde.
    Fehlt diese Information kann Exchange restauriert werden, aber beim ersten Start findet man im Eventlog die Meldung, wie es hätte sein sollen und darf dann noch mal anfangen.
  • Der Name der Site muss gleich sein
    Wenn man es nicht mehr weiß, siehe Organisation
  • Name des Servers muss gleich sein
    Wenn man es nicht mehr weiß, siehe Organisation
  • SID des Exchange Dienstkonto muss gleich sein
    Dabei zählt nicht der Name des Kontos und auch nicht der Domänenname, sondern die SID, d.h. die interne Nummer von Domäne und Konto. Diese erhalten sie nur, wenn noch ein Domaincontroller aktiv ist oder Sie diesen zuerst restauriert haben. Ohne dieses kommen sie nur noch an die "Inhalte" der Mailboxen ran, aber nicht mehr an das Verzeichnis, die Konfiguration oder die öffentlichen Ordner
  • Das Backup muss erfolgreich eine Datenbank gesichert haben.
    Klar. Ohne Band und Sicherung kein Restore

Einige "Fehler" kann man korrigieren durch eine Neuinstallation oder Reparaturen oder Änderungen mit REGEDIT und LDAP-Programmen, aber sie werden hier keine Anleitung zum knacken einer Exchange Datenbank finden und die Beschreibung jedes möglichen Desasterfalles sprengt auch diese FAQ-Seite.

Exchange 2000

Exchange 2000 arbeitet anders als Exchange 5.5. Daher sind auch die Voraussetzungen andere. Diese sind sogar um einiges "einfacher", da einige Bedingungen entfallen, aber andere ausgelagert wurden.

  • Der Name der Organisation muss gleich sein
    Hier zählt nicht der "Displayname", sondern der interne Name, welcher bei der Installation eingegeben (und hoffentlich dokumentiert ) wurde.
    Fehlt diese Information kann Exchange restauriert werden, aber beim ersten Start findet man im Eventlog die Meldung, wie es hätte sein sollen und darf dann noch mal anfangen. Problem hierbei ist aber, dass diese Information im Active Directory steht und daher der Neuinstallation erst eine saubere Exchange 2000 - Deinstallation vorangehen muss.
  • Der Name der Site muss gleich sein
    Wenn man es nicht mehr weiß, siehe Organisation. Sites bei Exchange 2000 heißen aber Administrative Gruppen und können umbenannt werden, sofern keine Exchange 5.5. Server in der Organisation sind. Ansonsten "neu" machen.
  • Name des Servers muss NICHT gleich sein
    Dies ist neu, da die Datenbank nicht mehr an den Server gebunden ist. Dies eröffnet einige alternative Restaurierungswege, z.B. über SAN und Ersatzserver eine Datenbank an einem anderen Server zu mounten.
  • SID des Exchange Dienstkonto ENTFäLLT
    Exchange 2000 kennt kein Dienstkonto mehr, wenn keine Exchange 5.5. Server im Standort sind.
  • Das Backup muss erfolgreich eine Datenbank gesichert haben.
    Klar. Ohne Band und Sicherung kein Restore

Mit diesem Wissen können sie schon sehr einfach eine existierende konsistente Datenbank (EDB und STM-Datei) an einem Notfallserver wieder anbinden und starten. Allerdings müssen Sie je nach Active Directory Restore die Mailboxen wieder neu verbinden oder andere Konfigurationen von Hand oder per Skript nachpflegen.

Restore-Szenarien

Siehe auch MSXFAQ.DE - Exchange NOTFALL - Serverdesaster 2000

Die Beschreibung, wie die Daten nun schrittweise zu restaurieren sind, erspare ich mir hier. Sie sind sowohl bei den Backupprogrammen sehr gut beschrieben (z.B. Veritas Backup Exec) und natürlich bei Microsoft. Die Links sind am Ende angegeben. Auf den folgenden Seiten finden Sie nun einige Betrachtungen zu verschiedenen Wegen einer Datensicherung und Restaurierung und welche Vor und Nachteile sich damit haben.

Der Weg eines Restore ist bei jeder Backupvariante beschrieben. Hierbei wird unterschieden nach:

  • Server Totalausfall
    Der alte Server ist nicht mehr da, z.B.: wegen Brand, Diebstahl oder anderen vollkommenen Verlusten ohne Chance noch mal an die Festplatten zu kommen. Ein neuer Server muss komplett frisch aufgesetzt werden und die Exchange Programme müssen neu installiert werden.
  • Datenbank korrupt oder Plattenausfall
    Nur die Datenbank muss restauriert werden.
  • Einzelne Mailbox verloren, gelöscht
    d.h., die Objekte einer Mailbox müssen nur restauriert werden

Eine genaue Beschreibung der Vorgehensweisen sollten Sie dem Exchange Desaster Recovery Paper oder der Produktdokumentation ihrer Datensicherungslösung entnehmen. Die Anleitungen hier dienen nur als Stütze für die schnelle Orientierung und natürlich damit sie eine Entscheidungsgrundlage haben, welche Datensicherung sie ihrem Exchange Server zukommen lassen. für einige Leser dürften die folgenden Seiten aber ebenso eine Offenbarung sein, wie sträflich Sie bisher ihr Backup vernachlässigt haben oder dass ihr aktuelles Backup eigentlich gar nicht richtig funktioniert.

Bitte informieren Sie sich auf der Seite Datenbankgrundlagen etwas über die Datenbank von Exchange und was sich dahinter verbirgt. Dass es eine Sammlung von Dateien ist, die permanent geöffnet ist und daher nicht per "COPY" gesichert werden können, dürfte ihnen nicht entgangen sein. Aber was verbirgt sich hinter den ganzen Dateien ?.

Erst wenn wir wissen, wie die Datenbank intern wirklich arbeitet, können wir auch die passenden Sicherungsstrategien entwickeln und die unterschiede zwischen den Optionen Vollbackup, Differenzsicherung, inkrementelle Sicherung, Offlinesicherung oder Schnappschusssicherung verstehen und einsetzen.