Backup und Restore - Vollbackup, Differenz, Inkrementell, Copy

Eine Sicherung von Exchange ist erst mal nicht anders zu betrachten, als eine Sicherung von anderen Systemen, nur mit dem Unterschied, dass es sich um eine Datenbank handelt. Und wenn wir mal die Sicherung einzelner Elemente (Mailboxen) außen vor lassen, dann lässt dich diese Datenmenge, die aus der eigentlichen Datenbank (EDB/STM-Dateien) und den Protokolldateien (LOG) nur komplett sichern. Trotzdem muss das Ergebnis nicht immer eine "Vollsicherung" sein. Wir können vier Methoden unterscheiden:

Warum Differenz und Inkrementelle Sicherung ?

Ein Ausfall, der ein Restore notwendig macht, liegt immer zwischen zwei Vollbackups. Nun kann es in bestimmten Umfeldern aber problematisch sein, wenn z.B.: nach einem Ausfall um 16:00 Uhr durch ein Restore eine Datenbank von 22:00 Uhr des Vortages zurückgesichert wird. Es fehlen dann alle Nachrichten der letzten 18 Stunden. Dies ist in der heutigen Welt kaum noch zu akzeptieren. Sofern die Protokolldateien den Ausfall überstanden haben, wird Exchange ein Rollforward machen und die Daten bis zum Moment des Ausfalls wiederherstellen. Aber was, wenn nicht ?. Und was passiert, wenn die Protokolldateien eines Tages meine Festplatten vollschreiben ?

Dann ist es an der Zeit auch unter Tage ab und an zumindest die Protokolldateien zu sichern. Fällt dann einmal der komplette Exchange Server komplett weg, dann kann ich auf dem neuen System erst die Datenbank wieder einspielen und dann die Protokolldateien von tagsüber und habe dann ein Restore, welches sehr nah an die Ausfallzeit herankommt.

Ich kenne Firmen, die dank Wechsler sogar stündlich die Protokolldateien wegsichern. Einige müssen dies aber auch tun, damit der Server nicht überläuft. Exchange Server mit Datenbanken jenseits der 100 Gigabyte Größe und einen Protokolldateiaufkommen von mehreren Gigabyte pro Stunde sind auch in Deutschland vorhanden.

Sicherung online

Gleich vorneweg: Die "Onlinesicherung" ist die einzige geeignete Sicherung um Exchange wirklich zu sichern. Tatsache ist aber auch, dass bis auf NTBACKUP alle anderen Hersteller für diese Option extra Geld haben wollen. Aber unabhängig davon sollten sich nicht zögern, dieses auszugeben.

Achtung:
Exchange 2007 SP1 schaltet per Default "Enable Remote Streaming Backup" ab, so dass Sie nur noch lokal sichern können. Über die Registrierung können Sie diese Funktion wieder aktivieren. Siehe auch SP 2007 SP1

Exchange wird dabei über eine API gesichert, über die die Datenbank die Information bekommt, dass sie gesichert wird. Dies findet sich auf im Eventlog als Meldung (Quelle: ESE98, ID:210=Backup gestartet bzw. ID:213=Backup erfolgreich beendet) wieder. Die aktuelle Protokolldatei wird unabhängig vom Füllstand raus geschrieben, d.h. alle Transaktionen werden in die Datenbank geschrieben und eine neue Protokolldatei und auch die PAT-Datei gestartet.

Jetzt erst liest das Backup sequentiell alle Datenbankseiten in 64 Kilobyte Paketen und schriebt diese auf dem Band. Dabei wird die Prüfsumme geprüft und damit ein Fehler bemerkt. Eine Onlinesicherung stellt also sicher, dass die Datenbankprüfsumme (CRC) stimmt, d.h. jede 64k Seite "korrekt" ist. (also prüft auf -1018 Fehler). Fallen nun neuen Transaktionen an, so prüft der Store, ob die betroffenen Seiten schon gesichert wurden. Wenn nicht, dann werden die Seiten sofort aktualisiert (also keine Schreibverzögerung in der Datenbank !!). Wurden die betroffenen Seiten schon gesichert, dann landen diese Veränderungen zusätzlich in der PAT-Datei, die am Ende gesichert wird.  Nach dem Backup sind alle Protokolldateien e[yy][xxxxx].log, die älter als der Start der Sicherung sind, löschen. Aber das macht das Backupprogramm selbst. Auf dem Band ist eine korrekte Sicherung und ein "Roll-Forward" vom letzten Backup ist nicht mehr notwendig.

Bei einer Restaurierung wird dann die Datenbank, die PAT-Dateien und die Protokolldateien zurückgespielt. Die eigentliche EDB-Datei auf dem Band ist losgelöst NICHT konsistent. Die restaurierte EDB-Datei wird beim ersten Start durch die Abarbeitung der Protokolldateien und das Einpatchen mittels PAT-Dateien in einen konsistenten Zustand versetzt. Und hier ist auch das größte Problem, wenn das Restore auf ein anderes System mit anderer Festplattenzuordnung erfolgt. In der Protokolldatei steht z.B. der Pfad der Datenbank fest drin, so dass dieser Buchstabe zumindest bis zum erfolgreichen Start nicht geändert werden kann. Mit ESEUTIL /MH priv.pat kann man nachsehen, welche Protokolldateien notwendig sind. Für näherer Details verweise ich auf die entsprechende Beschreibung des Backupprogramms und die Dokumentationen von Microsoft

Die Argumente für diese Sicherung liegen auf der Hand

Daher ist dies die einzig "richtige" Backupmethode. Diese unterstütz auch NTBACKUP.

Übrigens können sie mit diesem Agenten auch problemlos "Differenzsicherungen" fahren. Es hindert sie niemand daran, die Protokolldateien auch unter Tage wegzusichern. Sollte dann der komplette Server, d.h. die Festplatte mit den Datenbanken und die Festplatte mit den Protokolldateien ausfallen, können sie die Datenbank der letzten Vollsicherung restaurieren und die zwischenzeitlich gesicherten Protokolldateien einspielen und erhalten ein Exchange, welches bis auf die letzten Stunden wieder aktuell ist.

Keywords:Backup Restore Sicherung