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:

  • Vollbackup
    Die Datenbank wird komplett gesichert.
    Danach werden die Protokolldateien abgeschnitten
  • Differenzielles Backup
    Hier werden die Daten seit dem letzten Vollbackup gesichert. Genau genommen wird die Datenbank selbst hier nicht gesichert, sondern nur die Protokolldateien, welche aber nicht gelöscht werden
  • Inkrementelles Backup
    Hier werden die Daten seit dem letzten Vollbackup bzw. inkrementellen Backup gesichert. Genau genommen wird auch hier die Datenbank selbst nicht gesichert, sondern nur die Protokolldateien seit dem letzen Backup. Aber hier werden die Protokolldateien am Ende gelöscht. Dies ist eigentlich nur dann sinnvoll, wenn der Plattenplatz eng wird oder so viele Protokolldateien zwischen den Vollbackups entstehen, dass mehrere Differenzsicherungen dazwischen zu lange dauern würden.
  • Snapshot
    Diese Sicherungsmethode scheint zukünftig auch mit Exchange 2000 möglich zu sein, zumindest wenn man den Bildschirmausgaben von ESEUTIL glauben schenken darf. Hierbei wird eine Kopie der Datenbank während der Laufzeit gemacht (z.B. mit RAID-1-Systemen, die getrennt werden. So kann man eine sehr große Datenbank sehr schnell (innerhalb von Minuten) wieder erhalten und braucht nur noch die Protokolldateien nachholen. Aktuell kenne ich aber keine Programme oder Hilfsmittel, die dies unterstützen. Nach meinen letzten Infos sind diese Bildausgaben aber nur Reste eines Entwicklungszweigs, der nicht weitergeführt wird. Daher sind aktuell keine Snapshot Backups mit Exchange möglich. Windows.NET bieten entsprechende Schnittstellen für das Dateisystem an und was Exchange.NET bringen wird, darf ich nicht verraten.
    Einige Firmen machen dies heute schon so, dass die die Datenbank per Skript kurz "offline" nehmen, dann die Platten "splitten" und die Datenbank starten. Mit Exchange 2000 wird diese Zeit noch kürzer mit unabhängigen Speichergruppen. Einige Minuten "Pause" am Tag zu Gunsten einer sehr schnellen Rücksicherung im Fehlerfalle ist in einigen Umgebungen sinnvoll. Vermutlich werden die Firmen wie EMC² und andere hier die ersten Hilfsmittel liefern.
  • Kopie
    Das ist eigentlich eine Vollsicherung der Datenbank, nur bleiben die Protokolldateien bestehen. Insofern ist das eigentlich keine häufig genutzte Sicherungsmethode

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

  • Server ist 24h online
  • Mailverarbeitung läuft weiter
  • Konsistenzscheck der Datenbank
  • Defragmentierung wird nicht gestört
  • Protokolldateien werden bei Erfolg gelöscht

Daher ist dies die einzig "richtige" Backupmethode. Diese unterstützt 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.