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.:

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:

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.

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:

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.

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

Keywords:Datenbank Recovery Restore