Datenbank Wiederherstellung

Diese Seite beschreibt mögliche Schritte und Vorgehensweisen, um bei einem Defekt oder Ausfall einer Datenbank den Schaden zu reduzieren und die Ausfallzeit zu minimieren. Wie so oft gibt es aber nicht den einzigen Lösungsweg, sondern abhängig von der Ausgangssituation sind unterschiedliche Optionen denkbar. Ich Beschreibe daher die häufigste Variante, die von einem korrekten Exchange Backup ausgeht.

Wenn Sie andere Ausgangsvoraussetzungen haben, dann empfehle ich ihnen zumindest eine kurzes Telefonat mit einem Support Spezialisten, um den für sie optimalen Weg zu ermitteln.

ACHTUNG:
Sorgen Sie auf jeden Fall dafür, dass die Sicherungsmedien der fraglichen Zeit nicht überschrieben oder gelöscht werden. Es ist mir zu oft passiert, dass erst Tage oder Wochen die Fehler offenbar wurden und dann das letzte erfolgreiche Backup nicht mehr verfügbar war.

Ausgangssituation: Heile Welt

Exchange muss, wie jede andere Anwendung auch, korrekt gesichert werden. für Exchange ist das eine "online Datenbacksicherung" per API oder Schattenkopien, so dass Exchange während der Sicherung nicht herunter gefahren wird und am Ende nach Erfolg der Sicherung seine dann überflüssigen Transaktionsprotokolle löschen kann. Alle andere Sicherungen wie "Offline Backup oder Imaging ohne Schattenkopien betrachte ich nicht weiter.

Einige Firmen werden vielleicht auch unter Tage ab und an eine Sicherung der Transaktionsprotokolle durchführen, um die Verlustmenge bei einem Totalverlust der Serverplatten zu reduzieren. Wobei solche Firmen auch gut mit redundanten Disks und Ablagen (Cluster, CCR, SCR, LCR) fahren.

Entsprechend sollte ihr Protokoll dann wie folgt aussehen:

Zeit Aktion Beschreibung

Mo: 22:00

Fullbackup

Exchange Datenbank + Logfiles abschneiden

Di: 12:00

Differenzbackup

Exchange Logs sichern, nicht abschneiden

Di: 22:00

Fullbackup

Exchange Datenbank + Logfiles abschneiden

Mi:  12:00

Differenzbackup

Exchange Logs sichern, nicht abschneiden

Ihre individuelle Sicherungsplanung kann natürlich andere Startzeiten und Intervalle haben. Aber meist gibt es immer Vollsicherungen und in wenigen Fällen Zwischensicherungen. Dieser Anteil wird mit steigender Datenbankgröße aber zunehmen, da ein tägliches Vollbackup nicht mehr zu schaffen ist.

Der Ausfall: Was nie jemand für möglich gehalten hätte

Und nun ist Mittwoch Nachmittag und der Exchange Server hat ein "Problem". Es gibt viele Gründe, warum eine Exchange Datenbank korrupt werden kann, z.B.:

  • Cluster Failover mit Shared Disk Problemen
  • Disk "verloren", z.B. durch Fehler mit dem RAID-Controller
  • Virenscanner glaubt einen Virus gefunden zu haben und verhindert den Zugriff auf die Datenbank
  • Stromausfall "stört" Schreiben der Daten -> Datenblock korrupt (Checkdisk, -1018Fehler etc.)
  • Administratorfehler. Ja auch wir sind Menschen und ein Format ist schnell passiert.
  • SAN-Probleme "unterbrechen" den Schreibfluss Senden Sie mir doch ihren "Fehler", wenn er hier mit auftauchen sollte.

Quintessenz ist aber, dass Exchange die fragliche Datenbank nicht mehr startet, weil Sie "inkonsistent" ist. Mit einem ESEUTIL /MH sehen Sie das recht einfach. Im Normalfall können Sie Exchange starten und durch die Transaktionsprotokolle fällt die Datenbank wieder auf die Füße und arbeitet ohne Verluste weiter. Erschreckend ist für mich immer wieder, wie viele Administratoren solche Fälle gar nicht einmal bemerken. Sie merken es aber, wenn Exchange nicht mehr läuft. Und was dann ?

Reparatur oder Restore - Sein oder nicht sein

Es gibt Reparaturprogramme, die Fehler im Dateisystem (CHKDSK) oder Datenbank (ESEUTIL) wieder zu richten versuchen. Aber es gibt leider Fehler, deren Reparatur mit einem Datenverlust verbunden ist. Und sowohl im Dateisystem als auch in Exchange ist es sehr wohl ein unterschied, ob der Fehler in der hintersten Ecke nur ein paar Bits betrifft, oder quasi das Inhaltsverzeichnis und Verwaltungsinformationen beschädigt sind. Je nach Position ist vielleicht nur eine Datei oder einen Anlage einer Mail betroffen oder ein Order oder im schlimmsten Falle die ganze Datenbank.

Ich will damit ausdrücken, dass eine "Reparatur" nur der zweibeste Weg ist. Besser ist die Wiederherstellung von einer Sicherung und die Nutzung einer RollForward-Technologie. Exchange als Datenbank hat diese Funktion immer eingeschaltet während Dateisysteme diese Funktion meist nicht anbieten. Manchmal kann aber eine ebenfalls vorhandene Archivfunktion oder ein Differenzbackup in die Lücke springen und die Änderungen des Tages zurück holen.

Minimiere den Verlust !

Nun wäre es natürlich unfug, die defekten Dateien und Datenbank einfach wegzuräumen und Platz für die Wiederherstellung zu machen. Zum einen dauert die Wiederherstellung einige Zeit und je nach Szenario ist damit natürlich ein Datenverlust verbunden, den man gerne minimieren will.

Der saubere korrekte Weg ist immer eine Wiederherstellung vom Backup, aber das bedeutet nicht, dass man die defekte Dateien nicht noch für etwas sinnvolles nutzen kann. Also kopieren Sie die Daten immer auf eine weitere Festplatte. Wer weiß wozu die Daten noch einmal gut ein können.

Basis schaffen

Nun geht es darum die Basis für den Betrieb bereit zu stellen. Dazu gehört, dass man die Ursache für den Ausfall beseitigt, da sonst jede Reparatur und Wiederherstellung immer wieder auf den gleichen Fehler laufen kann. Es ist frustrierend, wenn man per Fernwartung einen Server "heil" gemacht hat und eine Stunde später der Kunde wieder anruft, dass der Fehler erneut aufgetreten ist. Da tröstet es auch wenig, wenn die Abrechnung pro Stunde erfolgt.

Wenn die Hardware, BetriebssystemUmgebung, Treiber und Konfiguration sauber sind, dann kann die Exchange Wiederherstellung erfolgen. Hier müssen Sie nun entscheiden, wie lange Sie ihre Anwender warten lassen wollen. Es gibt zwei Wege:

  • Datenbank  restauriere
    was Stunden dauern kann und die Mitarbeiter ohne Postfach dastehen lässt. Sie können als nicht mal auf neue Mails reagieren. Hier kann Exchange aber vorhandene Transaktionsprotokolle problemlos mit einbinden, so dass kaum Nacharbeiten erforderlich sind.
  • Dialtone Restore
    d.h. Sie starten Exchange mit "leeren" Datenbanken. Speziell vertriebsintensive Firmen können sehr schnell wieder neue Mails empfangen und darauf reagieren. Allerdings fehlen erst einmal die alten Mails. Man muss dann aber die alten Mails mit den zwischenzeitlich erstellten Objekten z.B. über die Recovery Storage Group  zusammenführen. Auch die Transaktionsprotokolle müssen gesondert behandelt werden.

Ich nehme an, dass die Mehrzahl der MSXFAQ-Leser daher lieber die Anwender ein paar Stunden länger "warten" lassen und den einfacheren Weg einer Wiederherstellung der Datenbank wählen.

Nach erfolgter Wiederherstellung hängt es nun davon ab, ob Exchange die noch vorhandenen Transaktionsprotokolle mit der Datenbank zusammenführen kann. Im Regelfall gelingt das alleine und es ist quasi kein Datenverlust festzustellen. Sollten die Transaktionsprotokolle fehlen, dann können Sie diese eventuell von einer Differenzsicherung noch restaurieren, ehe Sie die Datenbank starten.

Manchmal scheitert dies aber. Dann könnten Sie mit ESEUTIL /R manuell versuchen, die Datenbank mit den Transaktionsprotokollen bis zum Defekt konsistent zu machen. Viele werden aber einfach die Transaktionsprotokolle löschen und die Datenbank dann eben mit dem Stand der letzten Vollsicherung online schalten. Fakt ist dann, dass die letzten Mails (noch) fehlen.

Schürfen nach ....

Es hängt nun von der Wichtigkeit, Geld, Glück und ihrer Hartnäckigkeit ab, welche dieser Mails doch noch bereit gestellt werden können. Denn wir haben ja noch die zwar defekte aber vielleicht doch noch brauchbare Datenbank. Und diese kann man vielleicht doch noch als Quelle nutzen. Ohne Drittprogramme kann man die Datenbank über die Recovery Storage Group einbinden und die Inhalte überführen. Dazu müssen wir natürlich die defekte Datenbank erst mal wieder "konsistent" bekommen. Mit ESEUTIL und den Transaktionsprotokollen versuchen wir die Datenbank wieder konsistent zu bringen. Das die saubere Zusammenführung damals schon nicht geklappt hat, bleibt nur noch ESEUTIL /P. Mit etwas Glück ist die Datenbank danach konsistent und kann als Recovery Storage Group eingebunden werden.

Und dann sind es nur noch ein paar Mausklicks, um die aktuelleren Mails wieder in die Benutzerpostfächer zu übertragen.

Wenn die Bordmittel nicht weiterhelfen, gibt es noch weitere Optionen, z.B.

  • Backup
    Verschiedene Backupprodukte können einzelne Mails wiederherstellen. Früher wurden dazu auch einzelne Mails exportiert (Quasi wie mit EXMERGE). Aktuell können einige Produkte so gar aus der Datenbanksicherung einzelne Mails herausfischen. Das kann helfen, wenn mehrere Tage nachzuholen sind. Allerdings erhält man so keine Mails, die noch nicht im Backup gelandet waren
  • Archiv
    Wer ein Archivsystem einsetzt, kann hier nachschauen, ob die Mails vielleicht hier als Kopie liegen. Gerade mit der Journalarchivierung hat man gute Chancen, die Mails wieder zu bekommen. Dann fehlen zwar noch Termine  und Kontakte der Zwischenzeit aber das ist oft weniger kritisch
  • DrittTools
    Programme wie Power Controls, Quest Recovery Manager und andere versprechen auch aus defekten Datenbanken noch Inhalte retten zu können. Ein Versuch ist es wert. Die Erfolgschancen können Sie z.B. mit Power Controls direkt testen, da die Software als "ReadOnly"-Version frei verfügbar ist. Sie sehen also, was restauriert werden könnte.

Es gibt als sehr viele Optionen, nach einem Datenbankverlust, Defekt oder anderen Problemen wieder "online" zu kommen und vielleicht ganz ohne Datenverlust dazustehen.

Wenn Sie In der Sackgasse stehen ...

Vielleicht sind Sie anderen Quellen gefolgt und haben die defekte Datenbank mit einem "ESEUTIL /P" zwangsweise "konsistent" gesetzt und dann wieder online genommen. Schön für sie, dass ihre Anwender vermutlich sogar wieder arbeiten können aber fühlen Sie sich dabei wohl ?.

Schließlich nutzen Sie nun produktiv eine "reparierte" Datenbank, von der Sie zwar nun wissen, dass die Prüfsummen der verbliebenen Blöcke korrekt sind, aber ESEUTIL vermutlich einige defekte Blöcke einfach rausgeworfen hat. Erst ein ISINTEG könnte diese logischen Verbindungen prüfen. Vielleicht nerven Sie schon einige Anwender mit nicht genauer spezifizierbaren Fehlermeldungen der Form "Ein Clientvorgang ist fehlgeschlagen"

Vielleicht ist der Sachverhalt aber auch anders gelagert, dass die Datenbank ganz ohne Reparatur wieder "online" gegangen ist aber seit dem Zeitpunkt das Backup sich verweigert. Das kann passieren, wenn die Datenbank an einer Stelle kaputt ist (z-B. 1018 Fehler), aber Exchange selbst diese Seite beim Hochfahren gar nicht direkt verwendet. Das kann passieren, wenn die Datenbankseite eine Mail enthält, die eben nicht gelesen wird. Sie merken dies aber dann, wenn die Datensicherung diese Seite lesen kann und nicht darf. Exchange bricht dann das Backup ab und löscht auch keine Transaktionsprotokolle

In beiden Fällen haben Sie also eine Datenbank einige Stunden oder Tage weiter betrieben, die eigentlich keine gesunde Basis für einen Betrieb ist. Was dann ?. Auch hier geht die Funktion über die Wiederherstellung. Hoffentlich haben Sie sich die alten Sicherungsbänder vor dem Ausfall auch "gesichert". In Kürze machen Sie dann:

  • Optional: Exmerge-Export
  • Datenbanken offline nehmen
  • Prüfen auf Clean Shutdown
  • Datenbankendateien in Recovery Storage Group verschieben
  • Alte Datenbanken restaurieren
  • Transaktionsprotokolle laufen lassen (wenn möglich)
  • Alte Datenbank ist "online
  • Änderungen über Recovery Storage Group oder Exmerge importieren

EXMERGE

Wer sich doppelt absichern will, kann natürlich EXMERGE mit einbeziehen. Man kann mit EXMERGE automatisiert alle Mails von Postfächern in PST-Dateien extrahieren lassen. Man benötigt einen privilegierten Benutzer und die Datenbank muss dazu online sein. Die Anwender selbst können also sogar weiter arbeiten.

  • Export aller Inhalte
    ähnlich einen Single Mailbox Export kann man so ziemlich sicher gehen, dass die Elemente in der DB dann auch für Anwender lesbar sind. Sie erhalten aber keine Info, ob Elemente einfach nicht mehr da sind.
  • Export der letzten Elemente
    Wenn man so eine "unklare" Datenbank hat, dann kann man als Admin natürlich auch hier erst mal die Elemente seit dem Ausfall sicherheitshalber extrahieren. Sollte später das Rollforward der Transaktionsprotokolle nicht gehen oder die Recovery Storage Group nicht nutzbar sein (kein Platz ?), dann kann man so auch Mails wieder importieren.

EXMERGE exportiert aber nicht alle Elemente, die ein Postfach ausmachen. Der Weg, eine defekte Datenbank komplett zu exportieren und in eine leere Datenbank zu importieren. Berechtigungen und Regeln sind dann oft nicht mehr da.

Auch beim Export wird gerne übersehen, dass die Datenbank in der Zwischenzeit auch noch durch Anwender genutzt werden kann. Der Export der letzten Änderungen ist also nicht immer "vollständig". Hier ist der Merge über die Recovery Storage Group die bessere Wahl.

Weitere Links