Exchange 2010 Logfiles

[sakoti 11]

Wie sollte ich denn mit den Logfiles meiner Exchange 2010 Datenbanken verfahren?

Ich habe zum Teil knapp 90 000 Dateien im Ordner der Datenbank.

 

Kann ich die Logfiles löschen oder soll ich sie archivieren?

[Dukel 454]

Was für Logfiles? Error Logs oder Transaktionsptotokolle?

 

Im Ordner der Datenbank werden das wohl Transaktionprotokolle sein. Hast du ein funktionierendes Backup?

[RobertWi 81]

Also ich würde ein Backup einrichten, dann verschwinden die Logfiles von alleine.

[sakoti 11]

Es werden so 500-600 von den Files jeden Tag geschrieben und die sind 1 MB groß und haben die Bezeichnung "E000000000A".

 

Das werden Transaktionsprotokolle sein oder?

Fehler habe ich Exchange-seitig schon länger keine im Anwendungs-Eventlog.

 

Ich habe von jedem Tag ein Full-Backup, das ich so auch wiederherstellen kann.

[RobertWi 81]

Ich habe von jedem Tag ein Full-Backup, das ich so auch wiederherstellen kann.

 

Nein, zumindest keines, dass Exchange als Backup erkennt. Denn sonst würden die Log-Dateien verschwinden.

 

Was steht in den Eigenschaften der Datenbank als letzter Sicherungszeitpunkt? DAS ist der Zeitpunkt, an dem zuletzt ein korrektes Exchange-Backup gelaufen ist, danach nicht mehr.

[sakoti 11]

Die verschwinden aber, was ich gelesen habe nur beim Backup mit Windows-Sicherung.

 

Ich nutze aber DriveSnapshot, was Exchange wohl nicht erkennt. Es steht kein Zeitpunkt einer letzten Sicherung drinnen.

 

Was schlagt ihr für so einen Fall vor?

Soll ich die Files auf eine externe HD kopieren und dann löschen?

[NorbertFe 2.041]

Nein, du sollst ein Exchangekompatibles Backup benutzen, weil du nur damit eine garantierte Wiederherstellung hinbekommst. Mit Drivesnapshot kann alles passieren, auch dass es eben hinterher nicht mehr funktioniert.

[sakoti 11]

<p>Falls etwas schief gehen sollte, kann ja die Datenbank via eseutil in einen clean shutdown state versetzt werden.</p>

<p>Als Backup Software soll weiterhin DriveSnapshot genutzt werden.</p>

<p> </p>

<p>Brauche ich also unbedingt diese zig tausend Dateien??</p>

<p> </p>

<p>Würde es etwas nutzen, wenn z.B. einmal im Monat via Windows-Sicherung ein Backup erstellt und aufbewahrt wird, um die Transaktions-Dateien los zu werden??</p>

<p> </p>

<p> </p>

<p> </p>

<p>Oder anderes gefragt, ich brauche die Transaktionsdateien doch nur bei einem eventuellen Problem. Wenn ich ein funktionierendes Full-Backup vpm 15. September z.B. habe, brauche ich sämtliche Transaktionsdateien vor dem 15. September nicht?</p>

<p>Wenn jetzt heute z.B. ein Problem auftritt, reicht mir doch dieses Full-Backup vom 15. September + die Transaktionsdateien vom 15. bis heute?</p>

bearbeitet 18. September 2013 von shafner

[RobertWi 81]

Korrekt (was Norbert schreibt).

 

Snapshot-Sicherung sind bei Exchange unsupported, solange Exchange dies nicht als Sicherung erkennt. Deine Datenbank befindet sich immer in einem inkonsistenten Zustand, d.h. Du kannst theoretisch keine Log-Datei löschen, da Du nicht weiß, welche noch benötigt wird (mit Fachwissen kann man da schon was machen, das würde ich aber ungern so nebenbei im Forum erklären).

 

Ein zweites Backup hilft Dir nicht, da Du dann noch mehr Inkonsistenz bekommst. Und bei einem Recovery müsstest Du mehrfach wiederherstellen. Die einzig saubere Lösung (neben einem Backup) ist das aktivieren der Umlaufprotokollierung. Dann verlierst Du aber Daten bei einem Ausfall, zwischen Sicherung und Ausfall.

 

Du sicherst Deine DC hoffentlich nicht mit dem Programm, oder?

bearbeitet 18. September 2013 von RobertWi

[sakoti 11]

DC und Exchange befinden sich auf einem Server. Bislang hat mit DriveSnapshot alles wunderbar geklappt auch. Die Server wurden so schon auf andere Hardware migriert und es gab nie Probleme.

 

Oder anderes gefragt, ich brauche die Transaktionsdateien doch nur bei einem eventuellen Problem. Wenn ich ein funktionierendes Full-Backup vpm 15. September z.B. habe, brauche ich sämtliche Transaktionsdateien vor dem 15. September nicht?
Wenn jetzt heute z.B. ein Problem auftritt, reicht mir doch dieses Full-Backup vom 15. September + die Transaktionsdateien vom 15. bis heute?

[NorbertFe 2.041]

Falls etwas schief gehen sollte, kann ja die Datenbank via eseutil in einen clean shutdown state versetzt werden.

Falls etwas schief geht, kann ich mir auch mit dem Finger in der Nase bohren. ;) Wenn deinen Kunden ihre Daten kein "herstellersupportetes" backup wert ist, warum sichern sie dann überhaupt?

Brauche ich also unbedingt diese zig tausend Dateien??

Kommt darauf an.

Würde es etwas nutzen, wenn z.B. einmal im Monat via Windows-Sicherung ein Backup erstellt und aufbewahrt wird, um die Transaktions-Dateien los zu werden??

Ja, du hättest jeden Monat ein gültiges Backup. ;)

Oder anderes gefragt, ich brauche die Transaktionsdateien doch nur bei einem eventuellen Problem. Wenn ich ein funktionierendes Full-Backup vpm 15. September z.B. habe, brauche ich sämtliche Transaktionsdateien vor dem 15. September nicht?

Aber alle nach dem 15 September. ;) Und da die bei dir ja nicht vom Backup gelöscht werden, mußt du halt alle aufbewahren. Was machst du, wenn deine Datenbank den Fehler verursacht und du NICHT den kompletten Server restoren willst/darfst?

Wenn jetzt heute z.B. ein Problem auftritt, reicht mir doch dieses Full-Backup vom 15. September + die Transaktionsdateien vom 15. bis heute?</p>

Siehe oben.

 

Bye

Norbert

[sakoti 11]

Haltet ihr es für praktikabel / würdet es empfehlen, dass die DC /Exchange_Server anstelle von DriveSnapshot mit der Windows-Server Sicherung gesichert werden??

Zum Restore bei einer Sicherung mit Windows-Sicherung brauche ich ja, soweit ich weiß, nur die jeweilige Server 2008 CD?

[RobertWi 81]

Da Snapshot bei Exchange unsupported und bei DC hochgradig verboten sind, ist fast alles besser, als diese System mit einem Snapshot zu sichern. ;)

[sakoti 11]

Oder was wäre eine Alternative, die ihr empfehlen könnt für Exchange und DC?

Ist die integrierte Windows-Sicherung nicht gut?

[RobertWi 81]

Falsche Frage. Zuerst definiert man die Wiederherstellungs-Anforderungen.

 

Daraus leitet sich die Anforderung ans Backup ab.