Exchange 2013 Datenbank inkonsistent - wie "manuell" sichern und Konsistenz prüfen/reparieren?

[Blase 15]

Hallo,
 
ursprünglich komme ich aus einem anderen Thema, weil ich ein "normales" Sicherungsproblem ohne genauere Einschränkung hatte:

http://www.mcseboard.de/topic/197397-integrierte-windows-server-2012-sicherung-läuft-nicht/
 
Wie sich wohl herausstellte, habe ich speziell ein Exchange Problem, genauer scheint meine Datenbank wohl inkonsistent zu sein, weswegen die Sicherung nicht läuft. Ist ein Server 2012 Standard mit Exchange 2013 SP1 - alles soweit auf dem neuesten Stand.
 
Da ich über die integrierte Windows Server Sicherung keine Sicherung hinbekomme (siehe ursprüngliches Thema), ist die erste Frage natürlich, wie ich dann manuell meinen Exchange Server sichern kann. Einfach auf Dateiebene alles in "Mailbox" kopieren? Reicht das? Darf das auf der selben Maschine sein, oder muss das zwingend "runter" und wo anders hin? Die .EDB hat zur zeit keine 3 GByte und weil die Sicherung nicht läuft (noch nie lief, das System ist recht frisch) habe ich aktuell etwa 8000 .log Dateien dort drin. Wie gesagt, reicht das bezüglich Sicherung und FUNKTIONIERT das im Zweifelsfall überhaupt?
 
Die andere Frage, wenn ich die Sicherung erstellt habe, lautet natürlich, wie ich der Inkonsistenz auf die Schliche komme und diese beseitige. Ist "ESEUTIL" hier das Tool meiner Wahl?
 
http://support.microsoft.com/kb/259851/de

 

Also:

eseutil /g (Integritätsprüfung)

eseutil /p (Repair)

ISINTEG -s SERVERNAME -test alltests

 

Wäre das so die korrekte Reihenfolge meiner Tätigkeiten, um die Integrität meiner Exchange Datenbank wieder herzustellen und um letztlich wieder eine lauffähige Windows-eigene Sicherung zu realisieren?

 

Bin für Anregungen jeglicher Art offen!

 

MfG Blase

 

ps. liegt das an meinem Browser (IExplorer 11 => mcseboard.de als "vertrauenswürdige Seite" eingefügt), dass ich hier nichts "einfügen" (STRG + V) kann?! Auch die drei "einfüge" Buttons in der Maske oben scheinen keine Funktion zu haben, es passiert nichts. Nur wenn ich in den "BBCode Modus" wechsel, bekomme ich hier etwas eingefügt. Das aber nur am Rande - weil es das Schreiben hier deutlich erschwert.

bearbeitet 8. April 2014 von Blase

[RobertWi 81]

Moin,

 

http://www.mcseboard.de/topic/197397-integrierte-windows-server-2012-sicherung-läuft-nicht/
 
Wie sich wohl herausstellte, habe ich speziell ein Exchange Problem, genauer scheint meine Datenbank wohl inkonsistent zu sein, weswegen die Sicherung nicht läuft. Ist ein Server 2012 Standard mit Exchange 2013 SP1 - alles soweit auf dem neuesten Stand.

 

Wenn ich das richtig sehe, ist nicht die Datenbank inkonsistent, sondern nur ein Log-File.

 

Da ich über die integrierte Windows Server Sicherung keine Sicherung hinbekomme (siehe ursprüngliches Thema), ist die erste Frage natürlich, wie ich dann manuell meinen Exchange Server sichern kann. Einfach auf Dateiebene alles in "Mailbox" kopieren? Reicht das?

 

 

Das funktioniert zwar (wenn man weiß, was man macht), ist aber keine Sicherung.

 

Sinnvoller wäre es, das Problem zu löse.

 

 - Hebe die Bereitstellung der Datenbank auf (alle Benutzer werden getrennt!!!)

 - Stoppe den Dienst "Microsoft Exchange Information Store"

 - Wechsel in den Pfad "c:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\"

 

Prüfe den "State" der EDB-Date mit "eseutil /mh". Der State muss auf "Clean Shutdown" stehen.

 

Wenn ja: Lösche alle Datei in dem o.g. Ordner, bis auf den Unterordner mit der GUID und die EDB-Datei, als besonders die E00.log, E00xxxxxxxx.log und E00.chk.

 

Starte den Dienst wieder. Wenn alles ok ist, sollten die gelöschten Dateien mit Zähler "0" wieder neu angelegt worden sein und die Datenbank ist bereitgestellt.

 

Wenn das der Fall ist, probiere eine erneute Vollsicherung aus. Die sollte nun fehlerfrei sein.

 

WICHTIG: Alle Arbeiten auf eigene Gewähr! Falschbedienung kann zum Datenverlust führen! Wenn Du Dir nicht sicher bist, hol Dir jemanden ins Haus, der Dir hilft. Vor dem löschen schadet es nicht, einfach mal den Inhalt des Ordner zu kopieren.

 

Ach ja: Und wenn das Backup läuft, wäre das ein guter Zeitpunkt, die Datenbank von der C-Platte auf eine andere Platte/Partition zu bewegen.

 

ps. liegt das an meinem Browser (IExplorer 11 => mcseboard.de als "vertrauenswürdige Seite" eingefügt), dass ich hier nichts "einfügen" (STRG + V) kann?! Auch die drei "einfüge" Buttons in der Maske oben scheinen keine Funktion zu haben, es passiert nichts. Nur wenn ich in den "BBCode Modus" wechsel, bekomme ich hier etwas eingefügt. Das aber nur am Rande - weil es das Schreiben hier deutlich erschwert.

 

Das ist ein bekanntes Problem im MSIE 11. Nimm einen anderen Browser, dann geht auch einfügen.

[Blase 15]

Hallo Robert,

 

vielen Dank für Deine Hilfe.

 

Jetzt bin ich etwas verunsichert, wenn ich alle LOG Dateien herauslösche (und wohl auch nicht wieder anschließend einpflege), fehlen mir dann diese Informationen nicht in meiner Datenbank?! Die werden doch erst bei erfolgreicher Sicherung dort hinein geschrieben...?!

 

Wenn du sagst, dass wahrscheinlich eine LOG Datei mein Problem ist, kann man diese nicht finden und bereinigen oder zumindest nur diese löschen?

 

In diesem konkreten Fall kann ich die Datenbank nicht von C:\ verschieben, es gibt nur C:\. So ganz grundsätzlich, warum würdest du empfehlen, diese eben nicht auf C:\ zu haben? Ist das mehr als ein "kosmetischer" Effekt?

 

Danke für die Aufklärung bezüglich IE11 - habe schon eine mittlere Kriese deswegen bekommen ;)

 

Gruß

Björn

[NorbertFe 2.041]

Nein die werden spätestens beim Shutdown der Datenbank geschrieben. ;) Wäre ja schlimm, wenn das immer nur bei einer Sicherung erfolgen würde. Vor allem bei Backupless configuration, oder? ;) Deswegen sollst du auf clean shutdown achten.

 

Bye

Norbert

bearbeitet 8. April 2014 von NorbertFe

[Dukel 454]

Genauer gesagt, die Transaktionen werden dauernd in die Datenbank geschrieben (nicht nur beim Shutdown oder Backup). Bei einem Shutdown werden nur alle fehlenden Transaktionen in die Datenbank geschrieben. Und bei einem Log oder Full Backup werden eben diese Protokolle gelöscht (da alle in der Datenbank eingearbeitet sind).

[RobertWi 81]

Genauer gesagt, die Transaktionen werden dauernd in die Datenbank geschrieben (nicht nur beim Shutdown oder Backup).

 

Vereinfacht ausgedrückt, stimmt das. Genauer betrachtet ist es eigentlich komplett falsch. In einem anderen Forum erlebt jemand gerade, dass bei einem "unbenutzten" Server wochenlang Log-Dateien nicht in der EBD gelandet sind, sondern noch im RAM sind.

 

 

Bei einem Shutdown werden nur alle fehlenden Transaktionen in die Datenbank geschrieben.

 

Korrekt. Und wenn alles geklappt hat, ist die EDB danach "Clean Shutdown" und genau dann werden die Log-Dateien nicht mehr benötigt und können gelöscht werden. Und damit wird dann auch die defekte Log-Datei obsolet und kann weg und muss nicht mehr gesichert werden.

 

 

Und bei einem Log oder Full Backup werden eben diese Protokolle gelöscht (da alle in der Datenbank eingearbeitet sind).

 

Jein. In der Praxis werden nur die Log-Dateien gelöscht, die auf der Platte in der EDB sind. Genau das ist das Problem in den anderen Forum: Es werden GAR KEINE Log-Dateien entfernt, weil noch gar keine in der EDB-Datei sind. Das ist auch nur über die Sicherung aufgefallen, weil keine Logs abgeschnitten wurden.

 

In der Praxis sind niemals alle Log-Dateien enthalten und die, die noch fehlen, werden mitgesichert. Die EDB-Datei ist in einem Backup daher immer "Dirty Shutdown" (= es fehlen noch Logs).

 

In diesem Fall sind alle Logs enthalten und damit würden alle abgeschnitten. Da aber mindestens eine davon fehlerhaft ist, löscht man die einfach vorher. Da Exchange dann bei "0" mit dem Logs beginnt, meckert das Backup auch nicht.

 

Das einzige, was man beachten muss: Man muss nun unbedingt ein Fullbackup machen, weil ein inkrementelles aus Prinzip nicht mehr funktionieren kann.

[Blase 15]

Ok, war wohl mal wieder mein gefährliches Halbwissen am Start. Dachte bisher halt immer, dass, so lange die LOG Dateien noch "da" sind, diese Informationen nicht in der Datenbank stehen. Als "Beweis" dann das Verschwinden besagter Dateien bei einer Sicherung ;-)
 
Nur um noch einmal sicher zu gehen:

"Wenn ja: Lösche alle Datei in dem o.g. Ordner, bis auf den Unterordner mit der GUID und die EDB-Datei, als besonders die E00.log, E00xxxxxxxx.log und E00.chk."

 

Ich habe dort im Ordner die die besagten Dateien. Darüber hinaus habe ich aber auch .JRS Dateien (E00res0000A.jrs und aufsteigend). Auch weg? Und ich habe neben meiner "Mailbox.edb" auch noch eine "tmp.edb" (2 Mbyte) - die bleibt auch erhalten, ja?

 

Ich werde dann versuchen, dass heute Abend umzusetzen. Natürlich gebe ich dann hier Feedback.

 

Vielen Dank für die Hilfe!

 

Gruß

Björn

[RobertWi 81]

Ok, war wohl mal wieder mein gefährliches Halbwissen am Start. Dachte bisher halt immer, dass, so lange die LOG Dateien noch "da" sind, diese Informationen nicht in der Datenbank stehen.

 

Eventuell verwechselst Du auch nur was: Das, was Du schreibst wäre bei der sog. "Umlaufprotokollierung" der Fall. Sobald die aktiv ist, werden alle Log-Dateien gelöscht, die nicht mehr benötigt werden.

 

Die zu aktivieren könntest Du in Deinem Fall übrigens auch ausprobieren. Und wäre als erster Versuch mit weniger Risiko verbunden, als Dateien zu löschen.

 

 

Als "Beweis" dann das Verschwinden besagter Dateien bei einer Sicherung ;-)

 

Das ist nur doppelte Sicherheit. Mit den Log-Dateien auf der Platte (auch den bereits erledigten) könntest Du mit der letzten Sicherung den aktuellen Stand wieder herstellen. In der Sicherung ist die EDB +  unerledigte Logs, mit den noch vorhandenen kommt dann der aktuelle Stand. Das nennt sich "Rollforward" Recovery oder auch "Hard Recovery" bei eseutil.

 

Bei der Umlaufprotokollierung dagegen hast Du im Crash nur noch die Sicherung. Veränderungen sind gelöscht.

 

 Nur um noch einmal sicher zu gehen:

 

"Wenn ja: Lösche alle Datei in dem o.g. Ordner, bis auf den Unterordner mit der GUID und die EDB-Datei, als besonders die E00.log, E00xxxxxxxx.log und E00.chk."

 

Ich habe dort im Ordner die die besagten Dateien. Darüber hinaus habe ich aber auch .JRS Dateien (E00res0000A.jrs und aufsteigend). Auch weg? Und ich habe neben meiner "Mailbox.edb" auch noch eine "tmp.edb" (2 Mbyte) - die bleibt auch erhalten, ja?

 

Die JRS-Dateien (Platzreservierer falls "Platte voll") und tmp.edb kannst Du auch löschen. Die tmp.edb könnte sogar beim Dienstanhalten automatischer verschwinden.

 

Theoretisch ist am Ende wirklich nur noch die Datenbank.edb übrig (und der Ordner, weil das nicht die Datenbank sondern der FAST-Volltextindex ist).

 

 

Ich werde dann versuchen, dass heute Abend umzusetzen. Natürlich gebe ich dann hier Feedback.

 

Wir sind gespannt.

[Blase 15]

ich bin jetzt grade sehr vorsichtig...

"Die zu aktivieren könntest Du in Deinem Fall übrigens auch ausprobieren. Und wäre als erster Versuch mit weniger Risiko verbunden, als Dateien zu löschen."

 

... bin grade remote auf dem besagten System drauf und sehe den Punkt - kann ich den jetzt, im laufenden Betrieb und ohne eine "Sicherung" zu haben, diesen Haken einfach setzen?

 

Habe ich das so verstanden, dass er dann selbständig, nur durch das Setzen des Hakens, die nicht mehr benötigten LOG Dateien entfernen würde? Und die Hoffnung ist, dass die "Defekte" dabei ist? Also ich aktiviere die Umlaufprotokollierung, lasse ihn "rödeln" und versuche mich heute Abend dann erst einmal einfach an der Windows Sicherung. Schlägt die fehl, mache ich mit dem ursprünglichem Plan weiter...

 

Danke dir für die Erklärungen - vielleicht machen wir aus dem Blinden hier zumindest einen Einäugigen ;-)

EDIT - auch die Umlaufprotokollierung läuft dann nur zu den angegebenen Zeiten, ja? Also innerhalb des Wartungszeitraums? Macht es sinn, diesen dann uhrzeittechnisch vorzuverlegen (es wird niemand zu diesem Zeitpunkt mit Exchange/Outlook arbeiten), damit ich sehe, ob es was bringt und gleich mit dem ursprünglichen Plan fortfahren kann?

Und noch ein EDIT:

http://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenbank-vollgelaufen-was-tun/

 

Hier (und auf diversen anderen Seiten) steht, dass man die Umlaufprotokollierung eigentlich besser (grundsätzlich) nicht aktivieren sollte. Aber wenn man, wie wir hier vorhaben, die ganzen LOG Dateien rauslöschen will, dann "soll" man diese wohl (temporär?!) aktivieren, damit Exchange die LOGs nicht "vermisst"...?! Kannst du dazu etwas sagen?
 

[RobertWi 81]

ich bin jetzt grade sehr vorsichtig...

 

Das ist meistens besser, als einfach unbedarft drauflos löschen.

 

 

"Die zu aktivieren könntest Du in Deinem Fall übrigens auch ausprobieren. Und wäre als erster Versuch mit weniger Risiko verbunden, als Dateien zu löschen."

 

... bin grade remote auf dem besagten System drauf und sehe den Punkt - kann ich den jetzt, im laufenden Betrieb und ohne eine "Sicherung" zu haben, diesen Haken einfach setzen?

 

Ja, kannst Du. Aus dem Kopf weiß ich allerdings nicht, ob die Änderung sofort wirksam wird oder nur nach einem Neustart des Informationsspeicher-Dienstes.

 

 

Habe ich das so verstanden, dass er dann selbständig, nur durch das Setzen des Hakens, die nicht mehr benötigten LOG Dateien entfernen würde?

 

Korrekt.

 

Und die Hoffnung ist, dass die "Defekte" dabei ist?

 

Korrekt. Die defekte ist die Nummer 4, steht im Backup-Fehler.

 

Also ich aktiviere die Umlaufprotokollierung, lasse ihn "rödeln" und versuche mich heute Abend dann erst einmal einfach an der Windows Sicherung. Schlägt die fehl, mache ich mit dem ursprünglichem Plan weiter...

 

So wäre der Plan.

 

EDIT - auch die Umlaufprotokollierung läuft dann nur zu den angegebenen Zeiten, ja?

 

Nein, sie läuft immer. Sobald eine Log-Datei nicht mehr benötigt wird, wir sie gelöscht. Nur beim ersten Mal kann ein Neustart des Dienstes erforderlich sein.

 

Und noch ein EDIT:

 

http://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenbank-vollgelaufen-was-tun/

 

Hier (und auf diversen anderen Seiten) steht, dass man die Umlaufprotokollierung eigentlich besser (grundsätzlich) nicht aktivieren sollte.

 

 

Die Antwort lautet: Das kommt darauf an.

 

Der Nachteil (der einzige!) der Umlaufprotkolllierung ist, dass man im Crash-Fall nur auf den Zeitpunkt der Sicherung kommt und alles danach ist verloren.

 

Also gibt es zwei Gründe, die Umlaufprotokollierung zu nutzen (früher bei Ex 5.5. gab es noch einen dritten, kleine Festplatten):

1. man macht gar keine Backups. Ohne Backups werden die Log-Dateien nicht abgeschnitten und damit würde irgendwann die Platte volllaufen.

2. man hat irgendein Problem mit dem Backup oder den Log-Dateien und will/muss die loswerden.

 

Aber wenn man, wie wir hier vorhaben, die ganzen LOG Dateien rauslöschen will, dann "soll" man diese wohl (temporär?!) aktivieren, damit Exchange die LOGs nicht "vermisst"...?! Kannst du dazu etwas sagen?

 

Korrekt. Schreibt ja auch Frank: "Zu empfehlen ist allerdings der Weg über die Sicherung, die Logfiles löscht man nur im äußersten Notfall. " Aber genau diesen Notfall haben wir ja hier. ;)

 

Natürlich bin ich davon ausgegangen, dass Du nach der erfolgreichen Sicherung die Umlaufprotokollierung wieder deaktivierst.

 

Ablauf:

 - Umlaufprotokollierung einschalten

 - Sichern (zum Test, muss erfolgreich sein)

 - Umlaufprotokollierung aschalten

 - noch mal sichern (weil dass die Basis für die nachfolgenden inkrementellen ist)

[Blase 15]

Ok, ich werde nun "mutiger" mit der Thematik weil das gefährliche Halbwissen langsam weicht ;-)

 

Wenn ich jetzt die Umlaufprotokollierung aktiviere, sagt mir das System, dass das erst aktiv wird, wenn ich die Datenbank erneut eingebunden habe. Ich solle die Einbindung der Datenbank aufheben und neu einbinden.

 

Ok, grundsätzlich ja kein Problem, nur aktuell wird noch damit gearbeitet und ich würde den Kunden nur ungerne stören. Ich warte damit noch etwas und mache dann weiter....

 

Danke dir!

[RobertWi 81]

Ok, ich werde nun "mutiger" mit der Thematik weil das gefährliche Halbwissen langsam weicht ;-)

 

Wenn man einmal hinter die Technik gestiegen ist (ich habe das da oben mit dem Log-Dateien löschen bestimmt schon 50 Mal bei Kunden und in Kursen live gezeigt), dann merkt man, dass die Entwickler auch nur mit Wasser kochen und Exchange zwar komplex, aber dennoch keine Raketentechnik ist.

 

Trotzdem schadet eine gewisse Vorsicht nie.

 

Wenn ich jetzt die Umlaufprotokollierung aktiviere, sagt mir das System, dass das erst aktiv wird, wenn ich die Datenbank erneut eingebunden habe. Ich solle die Einbindung der Datenbank aufheben und neu einbinden.

 

OK, dann nicht der Dienst, nur die Einbindung. Kommt ja aber am Ende auf das gleiche raus, die Benutzer werden getrennt.

 

Ok, grundsätzlich ja kein Problem, nur aktuell wird noch damit gearbeitet und ich würde den Kunden nur ungerne stören. Ich warte damit noch etwas und mache dann weiter....

 

Gut, dann warte ich gespannt. :)

[NorbertFe 2.041]

DB dismount und remount dauert keine 30sek und wenn der cachemodus aktiv ist an den Outlook merkt nicht mal jemand was davon.

[Dukel 454]

Evtl. kann man auch ne 2. DB erstellen, alle Postfächer umziehen (das geht ja Online) und die alte DB dann reparieren (oder gleich weg werfen, da man ja dann eine funktionierende DB hat).

[RobertWi 81]

Gibt meist mehr Lösungen. Aber nur mit den schwierigen Aufgaben wächst man. :) Wenn das mit den Logs funktioniert, ist das ein guter Lerneffekt, wenn mal wirklich Stress ist.

 

Und wenn nicht, kann man immer noch umziehen.