Jump to content

Exchange 2019 DAG - Log Files werden nach Backup nicht entfernt


dmks.23
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hi Leute,

 

ich hab einen Exchange-Server hier, welcher nach Einrichtung des DAG die Logs nicht automatisch löscht.

Fehlermeldung im Truncating Log finde ich leider auch keine.

Sobald ich die DB-Kopie entferne und eine Vollsicherung durchführe (Windows Backup), werden die Logs auch korrekt entfernt. Ist eine DB-Kopie vorhanden passiert nichts.

 

Updatestand: CU12 + aktuelle Windoofupdates'

Alle DB's liegen auf eigenen Laufwerken, sowie dessen Logs.

 

Als eigentliche Backuplösung wird in diesem Falle Dell verwendet. Der Fehler lässt aber wie schon erwähnt mit dem WindowsBackup nachstellen.

VSSwriter wurde bereits geprüft > alles i.O.

DB's wurden neu erstellt und Postfächer migriert. Da hätte ich noch die Frage müssen die Logs mindestens 100MB groß sein bevor der Exchange Server anfängt Diese zu löschen?

 

Grüße,

 

DerMarKuS

 

 

 

Link zu diesem Kommentar

Moin,

 

wenn Logs nicht gelöscht werden können, wird es im Application EventLog protokolliert. Auch wenn sie abgeschnitten werden, wird es dort protokolliert. Dass man nach dem Hinzufügen und Entfernen von Kopien den Information Store neu starten muss, hast Du berücksichtigt?

Sicherst Du die aktive oder die passive Kopie? Falls die aktive Kopie klappt und die passive nicht, ist die Cluster-Kommunikation kaputt.

Exchange schneidet die Logs nicht auf Null an, sondern behält einige. Vor Einführung der DAG waren das, meine ich, acht (á 5 MB), ab Exchange 2010 sind es mehr, allerdings á 1MB, 100 könnte hinkommen.

 

Link zu diesem Kommentar
vor 12 Minuten schrieb cj_berlin:

Moin,

 

wenn Logs nicht gelöscht werden können, wird es im Application EventLog protokolliert. Auch wenn sie abgeschnitten werden, wird es dort protokolliert. Dass man nach dem Hinzufügen und Entfernen von Kopien den Information Store neu starten muss, hast Du berücksichtigt?

Sicherst Du die aktive oder die passive Kopie? Falls die aktive Kopie klappt und die passive nicht, ist die Cluster-Kommunikation kaputt.

Exchange schneidet die Logs nicht auf Null an, sondern behält einige. Vor Einführung der DAG waren das, meine ich, acht (á 5 MB), ab Exchange 2010 sind es mehr, allerdings á 1MB, 100 könnte hinkommen.

 

Der Fehler kommt bei passiven, sowie aktiven Kopien zu Stande.

Ja Information Store wurde mehrfach neugestartet. Die Datenbanken haben wir auch zum Tests einmal über die Shell erstellt. Ohne Erfolg

Folgende Logs finde ich im Application Log:

Quelle: ESE  ID: 225

Quelle: MSEXCHRepl ID: 2046

 

Jedoch keine Warnung oder Fehler

 

Wir haben auf anderen Datenbanken auch deutlich mehr Log-Files, ca. 500. Dort befinden sich Logs die schon älter als ein Monat sind.

 

Link zu diesem Kommentar
vor 1 Stunde schrieb dmks.23:

Quelle: ESE  ID: 225

Quelle: MSEXCHRepl ID: 2046

Danke für das Vertrauen darauf, dass wir alle Event IDs von Exchange auswendig können.

Aber mal anders gefragt: Nach einem Backup mit zwei Kopien, wird da der Backup-Zeitstempel auf der Datenbank gesetzt? Falls ja, hast Du kein Problem, und es sind in der Tat "zu wenige" Logs.

Link zu diesem Kommentar
vor 16 Stunden schrieb NorbertFe:

Wieviele Logs sind das und welches Backupprodukt nutzt ihr? Wenn "zu wenige" Logs vorhanden sind, werden die ggf. erst beim nächsten Mal entfernt. Kenne ich vom Kunden mit Veam und 4 Node Cluster.

500 Logs waren es bei der größten DB. Wir nutzen Dell Networker, das mit Veam habe ich auch schon gelesen, traf aber bei uns nicht zu, weil das Problem ja auch bereits beim Windows Backup besteht.

 

vor 15 Stunden schrieb cj_berlin:

Danke für das Vertrauen darauf, dass wir alle Event IDs von Exchange auswendig können.

Aber mal anders gefragt: Nach einem Backup mit zwei Kopien, wird da der Backup-Zeitstempel auf der Datenbank gesetzt? Falls ja, hast Du kein Problem, und es sind in der Tat "zu wenige" Logs.

Haha ja sorry deine Aussagen waren so kompetent, da dachte ich du weißt das auswendig :d

Die Zeitstempel vom Backup werden korrekt gesetzt.

vor 15 Stunden schrieb tesso:

Die Fehler geben her das du den Server neustarten solltest. Wenn das nicht hilft ein Ticker bei MS eröffnen sollst.

Server wurden auch neugestartet, jedoch ohne Erfolg.

Link zu diesem Kommentar

Moin,

wenn der Zeitstempel korrekt gesetzt wird, scheint alles zu funktionieren. In einer DAG werden ja mehr Logs vorgehalten, wenn mehrere Kopien vorhanden sind, daher würde ich etwas mehr Zeit zwischen den Backups verstreichen lassen, so dass vielleicht ein paar Tausend Logs auflaufen, und dann schauen, wieviele davon verschwinden.

Link zu diesem Kommentar
vor 3 Minuten schrieb cj_berlin:

Moin,

wenn der Zeitstempel korrekt gesetzt wird, scheint alles zu funktionieren. In einer DAG werden ja mehr Logs vorgehalten, wenn mehrere Kopien vorhanden sind, daher würde ich etwas mehr Zeit zwischen den Backups verstreichen lassen, so dass vielleicht ein paar Tausend Logs auflaufen, und dann schauen, wieviele davon verschwinden.

Ja täglich grüßt das Murmeltier. Du hast recht, eben grade reingeschaut Logs wurden abgeschnitten. Nun Frage ich mich wo liegt hier für Exchange die Grenze, weiß das jemand?

Link zu diesem Kommentar
vor 44 Minuten schrieb tesso:

Sind evtl. die Logs noch nicht in alle Datenbanken geschrieben worden? Arbeitet ihr mit verzögerten Kopien?

Also ich hab jetzt immer nur die anzahl der Logs verglichen passiv und aktiv und naja Eventlog ist halt leer. Kann ich das über die shell live loggen, für eine DB?

 

Hatten wir auch schon bereits in Vermutung, aber wurde hier nicht eingerichtet.

 

Link zu diesem Kommentar
  • 4 Wochen später...

Also nach einiger Beobachtung scheint es tatsächlich unnötige Sorge gewesen zu sein.

Logs wurden überall von Zeit zu Zeit abgeschnitten. Es muss hier also einen Grenzwert geben, der das Entfernen regelt. Wo der liegt hab ich aber nicht herausfinden können.

Meine Vermutung ab 1GB an Logfiles wird angefangen zu bereinigen. Die größe des Log-Files selbst spielt dabei eine untergeordnete Rolle.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...