Was kann ich unternehmen wenn die Partition/Festplatte auf der die Exchange Datenbank gespeichert ist, vollgelaufen ist und der Informationsspeicher seinen Dienst aufgrund von zu wenig freiem Speicher verweigert?
Erfahrungsgemäß ist es nicht die Größe der Exchange Datenbanken, die eine Partition volllaufen lässt, sondern die Logfiles der Datenbanken nehmen im Laufe der Zeit den freien Speicher in Beschlag.
Aber warum?
Exchange speichert zu jeder Aktion in der Datenbank einen Eintrag in einem Transaktionsprotokoll der Datenbank ab, jedes Transaktionsprotokoll ist 1 MB groß, wenn ein Log voll ist, wird ein neues begonnen.
Warum macht Exchange so was?
Sollte die Datenbank einmal einen Defekt oder eine Inkonsistenz aufweisen, können die Transaktionsprotokolle, die ja alle Änderungen der Datenbank enthalten, dafür benutzt werden die Datenbank wieder in einen konsistenten Zustand zu bringen (siehe auch hier: https://www.frankysweb.de/?p=342). Exchange speichert also solange Logs, bis…
Wie werde ich die Logfiles los?
… bis die Datenbank gesichert wird. Sobald die Datenbank gesichert wurde, gibt es keinen Grund mehr, die Logfiles aufzubewahren. Exchange löscht dann die Logfiles. Das funktioniert allerdings _NUR_ wenn die Methode oder das Programm, welches zur Sicherung von Exchange verwendet wird, auch Exchange kompatibel ist. Eine Software die einen Snapshot der Exchange VM oder ein Image des Exchange Servers erstellt, muss auch Exchange mitteilen, das die Logs gelöscht werden können. Bleibt diese Information der Sicherungssoftware aus, werden Logs geschrieben, bis auch die größte Festplatte voll ist.
Beispiel:
In diesem Bild sieht man eine Datenbank (grün) mit einer Größe von 72 GB, die Datenbank wurde seit 2 Tagen nicht gesichert, daher gibt es auch viele Logfiles (orange) zu der Datenbank. Insgesamt gibt es innerhalb von 2 Tagen bereits knapp 1900 Logfiles mit je 1 MB Größe.
Innerhalb von 2 Tagen wurden also schon knapp 1,9 GB an Logfiles geschrieben. Die Datenbank enthält übrigens nur ca. 50 Benutzer Postfächer. Es kann also schnell knapp werden mit dem Speicherplatz, gerade wenn um einiges mehr Postfächer innerhalb der Datenbank liegen, oder die Sicherung 2 Wochen lang nicht läuft.
Was kann aber nun unternommen werden, wenn das Volume voll ist?
Möglichkeit 1:
Der sicherste Weg die Logs loszuwerden ist eine Sicherung des Exchange Servers mit einem kompatiblen BackUp Programm. Auf die Schnelle kann dazu die Windows Server Sicherung verwendet werden. Das ist auch zugleich der einfachste Weg: Feature Windows Server Sicherung installieren, Einmalsicherung konfigurieren (VSS Einstellungen – Vollständige VSS-Sicherung), auf Netzlaufwerk oder USB-Festplatte sichern, fertig. Die Logs sind dann gelöscht worden und es sollte wieder Speicherplatz frei sein. Die Sicherung wird wie folgt konfiguriert:
Benutzerdefinierte Sicherung auswählen
Dann die Partition mit „Elemente hinzufügen“ auswählen, die die Exchange Datenbanken enthält. Unter „Erweiterte Einstellungen“ muss folgendes ausgewählt werden
In den VSS-Einstellungen ist es wichtig „Vollständige VSS-Sicherung“ auszuwählen, sonst werden die Logs nicht gelöscht. Im letzten Schritt wird noch das Sicherungsziel ausgewählt und es kann losgehen.
Jetzt heißt es warten bis die Sicherung fertig ist, das kann bei vielen Logs und einer großen Datenmenge natürlich etwas dauern. Wenn es schnell gehen muss, gibt es noch eine weitere Möglichkeit.
Möglichkeit 2:
Wenn die Datenbank im Clean-Shutdown State ist, also von Exchange sauber runtergefahren worden ist, dann sind bereits alle Logs in die Datenbank eingespielt. Es gilt also zuerst zu prüfen ob die Datenbank sauber runtergefahren wurde. Das geschieht mit dem Befehl „eseutil“ auf der Kommandozeile:
eseutil /mh „NameDerDantenbank.EDB
Wenn der Wert bei State „Clean Shutdown“ ist, ist alles in Ordnung und es kann weiter gemacht werden, wenn der Wert bei State „Dirty Shutdown“ entspricht, bitte hier weiterlesen. Der nächste Schritt ist, alle Transaktionsprotokolle mit der Endung .log auf ein anderes Volume oder Netzlaufwerk zu verschieben. Nach dem Verschieben sollte wieder Platz auf dem Volume sein. Jetzt muss die Umlaufprotokollierung der Datenbank aktiviert werden, damit Exchange die verschobenen Logfiles nicht „vermisst“.
Die Umlaufprotokollierung kann in den Eigenschaften der Datenbank konfiguriert werden, dazu muss nur ein Häkchen gesetzt werden
Danach kann die Datenbank wieder gemounted werden. Zu empfehlen ist allerdings der Weg über die Sicherung, die Logfiles löscht man nur im äußersten Notfall. Die Umlaufprotokollierung sollte auch umgehend wieder abgeschaltet werden.
Und was kann ich machen damit das nicht wieder passiert?
Regelmäßige Backups der Datenbanken mit einer kompatiblen Software reduzieren die Gefahr, dass die Festplatte mit Logs vollläuft um einiges. Sinnvoll ist auch eine Überwachung der Volumes auf freien Speicherplatz. Wenn keine Monitoring Lösung eingesetzt wird, kann auch der „Ressourcen-Manager für Dateiserver“ von Server 2008 R2 verwendet werden, um eine Warnung zu bekommen, wenn der Speicherplatz knapp wird. Der Ressourcen Manager ersetzt natürlich keine Monitoring Software, aber ist in dem Fall besser als nichts.
Der Rollendienst „Ressourcen-Manager für Dateiserver“ kann im Servermanager als Rollendienst für die Rolle „Dateiserver“ hinzugefügt werden
Schon bei der Installation können die Volumes ausgewählt werden auf die der Speicherplatz überwacht werden soll
Mit dem Klick auf „Optionen“ können die Berichte konfiguriert werden, hier können alle Berichte abgewählt werden. Der Nutzungsschwellenwert ist auf 85 % eingestellt, es wird also bei 85%iger Auslastung des Volumes wird benachrichtigt. Welcher Wert hier sinnvoll ist, hängt von der Größe des Volumes ab. Im nächsten Dialog kann auch gleich ausgewählt werden, dass eine Warnung, bzw. der Bericht per Mail verschickt werden soll
Nach der Installation des Rollendienstes können die Einstellungen in der Konsole „Ressourcen Manager für Dateiserver“ konfiguriert werden. Zunächst ein paar allgemeine Optionen, wie Absender und Standard Empfänger, siehe folgende Screenshots
Danach muss noch angehakt werden, dass eine Warnung per Mail verschickt werden soll, wenn der Speicherplatz knapp wird.
Hallo Frank,
Shadows sind keine gelistet. Ich habe jetzt mal im Ereignisslog geschaut, zum Endzeitpunkt der WIndows Serversicherung liegen keine VSS-Meldungen vor. ESE Meldungen sind da, teilen mir aber nur mit, dass eine neue Instanz für die jeweilige Datenbank gestartet und/oder eine neue Datenbank angefügt worden ist.
ich hab mal mit Get-MailboxDatabase -status | fl name, *backup eine Abfrage gemacht, als LastFullBackup ist überall nichts eingetragen.
Jetzt bin ich mir aber nicht sicher, ob es nicht ggf. an einer Migration liegen kann. Ich habe einige Datenbanken in mehrere kleine Datenbanken aufgetrent und die Postfächer migriert. Nachdem ich die (DAG-) Datenbank auf einem passiven Servern dismountet und dort mit eseutil /MH geprüft habe, stand dort für die Datenbank folgendes:
State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)
Somit bräuchte er die Logs ja gar nicht (300GB!). Bin verwirrt, ob das alles miteinander zusammenhängt.
Grüße,
Mustafa
Hi,
ich denke wir reden da gerade an einander vorbei :-)
War die Datenbank zum Zeitpunkt der Sicherung online oder offline? Wenn die Datenbank offline war, werden keine Logs gelöscht. Die Datenbank muss online sein, du kannst aber vom passiven Knoten sichern, in dem Fall werden die Logs gelöscht.
Gruß, Frank
Das ist mir schon klar :) Sie war zum Zeitpunkt der Sicherung online, gesichert wurde der passive knoten.
Ich hab nur nach def Sicherung die Datenbank offline genommen und mit eseutil nach dem Status geschaut.
Gelöscht wurden Sie aber während der Sicherrung nicht, obwohl diese Erfolgreich war. Im Ereignislog steht auch kein Fehler
Ah ok, jetzt verstehe ich :-)
Die Datenbank ist nach einem erfolgreichen Offline schalten immer im Clean Shutdown State.
Hast du mittels VSS eine Vollsicherung oder eine inkrementelle Sicherung durchgeführt?
Gruß, Frank
Ich habe eine VSS-Vollsicherung gemacht. Normal haben wir Veeam in Version 9 dafür, löscht die Logs aber nicht. Gestern und heute habe ich deinen Tip oben ausgeführt, immernoch nicht besser.
Jetzt frage ich mich:
Wenn die Datenbank im Status Clean Shutdown ist (nach dem Sichern trennen) braucht Sie die Logfiles ja nicht. Kann ich die nicht auf allen Knoten (aktiv und passiv) löschen und dann erneut einbinden?
Es sind keine VSS oder ESE Fehlermeldungen im Eventlog.
Hallo Frank,
wann werden die Logs denn gelöscht? Wir haben eine DAG mit drei Servern. Davon wird einer in Verbindung mit einem DC täglich gesichert. VEEAM ist auf Application Aware Sicherung eingestellt, aber die Logs bleiben dennoch da.
Jetzt habe ich den Tip von Oben mit der VSS Sicherung durchgeführt und 1,7TB erneut gesichert, aber Logs sind immernoch da.
Grüße,
Mustafa
Hi Mustaja,
normalerweise werden die Logfiles gelöscht, wenn das Backup erfolgreich abgeschlossen ist. In der Ereignisanzeige solltest du nach und während des Backups ESE und VSS Meldungen erhalten, die geben Aufschluss darüber, warum die Logs nicht gelöscht werden. Ich nehme an, das bei dir VSS Probleme vorliegen und Exchange „nicht mitgeteilt“ bekommt, das die Sicherung erfolgt ist. Entsprechende Hinweise sollten sich dann wie schon erwähnt in der Ereignisanzeige unter „Anwendung“ finden lassen.
Gruß, Frank
PS: Schau auch mal nach ob es ggf. noch VSS Snapshots gibt, die nicht aufgelöst wurden, manchmal verhindern die das Löschen der Logs: vssadmin list shadows
Hallo Jan,
Also ich weiss jetzt nicht wie du Veeam konfiguriert hast aber bei einer erfolgreichen „Application-Aware“ Sicherung werden die Transaktionsprotokolle einwandfrei weggelöscht das gleiche gilt auch für ein Exchange DAG!
Gruss
Roman
Für den Fall das auch diese Email nicht beachtet wird, kann man sich noch ein / zwei Platzhalter-Files in das Volume legen. Diese kann man dann gefahrlos bei Bedarf löschen. So gewinnt man etwas Zeit für eine ordentliche Sicherung. Der Befehl „fsutil file createnew platzhalter.xxx 1000000000“ legt z.B. eine ca. 1GT große Datei an.
Gruß,
Sven
Hi Frank,
sehr nützlicher Beitrag, vielen Dank! Ich nutze auch auf unserem Xchange die Windows Server Sicherung, obwohl wir schon nen Snapshot über Veeam Backup vom Xchange machen. Leider werden die Transaktionsprotokolle dabei nicht gelöscht. Mir hat nur die richtige Option vollständige VSS-Sicherung gefehlt. Hoffentlich sind die Transaktionsprotokolle morgen weg.
Grüße aus FFM
Jan