Hallo Zusammen, ich habe einige Fragen an die Experten in diesem Forum
Frage1:
Was bedeutet diese EventID 1013, muss ich mir Gedanken machen?
The size of this folder X:\\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs has reached 70% of max size allowed - 5120 MB. Some data will be purged once it reaches the max limit " .
Gehe ich recht in der Annahme, dass dieser Diagnosticdienst den Log-Ordner nur auf 5120MB anwachsen lässt und nur die darin befindlichen Logs löscht?
Frage2:
Ich habe eine Verständnisfrage zur manuellen Weg-Sicherung einer Postfachdatenbank - könnte man folgendes so machen:
Datenbank aushängen, Informationsspeicherdienst stoppen, kompletten Ordner "Postfachdatenbank" mit der Datenbank darin sichern, bzw. auf externe Platte kopieren.
Kann man bei einem Crash der aktuell verwendeten Datenbank, die oben genannte Sicherung einfach wieder an den ursprünglichen Ort zurückkopieren und die Dienste wieder hochfahren, bzw. die Datenbank wieder ohne Probleme einhängen?
Frage3
Wir haben Veeam im Einsatz und die Hauptserver sind auf einem VMwareCluster/Stormagic mit zwei Nodes als VM installiert, darunter auch der Exchange2016 CU22.
Habt Ihr einen Tipp für mich, wie ich am besten den Exchangeserver mit Veeam sichere, sodass beim Backup die Exchangedatenbank nicht korrupt wird, bzw. beschädigt nicht wird?
VM mit dem Veeam Job anhalten (vmwaretools quiescence), oder Veeam Job mit application-awareness image, oder Veeam Agent direkt auf dem Exchangeserver installieren?
Vielen Dank vorab für Eure Anteilnahme!
MfG
und nur die darin befindlichen Logs löscht?
Ja. Genau das steht in der Meldung.
könnte man folgendes so machen:
Datenbank aushängen, Informationsspeicherdienst stoppen, kompletten Ordner "Postfachdatenbank" mit der Datenbank darin sichern, bzw. auf externe Platte kopieren.
Kann man machen, aber warum? Eine Sicherung ist das nicht im eigentlichen Sinne und eine downtime hast du logischerweise auch jedes Mal.
Habt Ihr einen Tipp für mich, wie ich am besten den Exchangeserver mit Veeam sichere, sodass beim Backup die Exchangedatenbank nicht korrupt wird, bzw. beschädigt nicht wird?
Ist der Exchange eine vm? Dann die vm sichern und application awareness aktivieren. Dann siehst du im eventlog des exchangeservers, dass die Sicherung durchgeführt wurde. Ich würde behaupten, dass man bei veeam eine Antwort auf diese Frage finden würde. :)
Vielen Dank für deine Antwort.
Zu 2 und 3:
Der exchange ist eine VM. Unsere Hauptpostfachdatenbank ist aus irgendeinen Grund nicht mehr eingebunden worden. Ein Postfach hätte den Crash dieser Datenbank verursacht, dies sagt das Log.
Wir mussten mit eseutil die Datenbank erst wieder sauber bekommen, bevor diese sich wieder einbinden lassen hat. Da wir nun wieder einen funktionierenden Exchangeserver hatten, hatte ich nun den Ordner mit der Clean Datenbank nochmal weggesichert. Ich war mir allerdings nicht sicher, ob ich den weggesicherten Ordner wieder einfach verwenden kann, falls die jetzt eingebundene Datenbank mal wieder crasht. Nebenbei gesagt taucht nach der Reparatur jetzt stündlich der Hinweis auf, dass man dieser Datenbank nicht mehr trauen könnte weil es nötig war eseutil zu benutzen - die Postfächer sollen sobald wie möglich in eine neue Datenbank verschoben werden.
Ich grübele schon die ganze Zeit was diesen Crash tatsächlich verursacht hat - hat dieses eine Postfach wirklich den ganzen Exchangeserver lahm gelegt? Oder hat veeam auf dem Exchange etwas kaputt gemacht, weil der Veeam-Job für den Exchange nicht richtig eingestellt war oder veeam das Ganze beim kopieren vorher vielleicht nicht in einen ordentlichen State gebracht haben könnte?
MfG
Ich grübele schon die ganze Zeit was diesen Crash tatsächlich verursacht hat - hat dieses eine Postfach wirklich den ganzen Exchangeserver lahm gelegt?
Dazu müsste man schon wissen was genau passiert ist und was in den logfiles genau stand/steht.
die Postfächer kann man ja einfach in eine neue „saubere“ dB migrieren, wenn man den Platz hat. ;) ne Sache von überschaubarer Komplexität.
Oder hat veeam auf dem Exchange etwas kaputt gemacht, weil der Veeam-Job für den Exchange nicht richtig eingestellt war oder veeam das Ganze beim kopieren vorher vielleicht nicht in einen ordentlichen State gebracht haben könnte?
Unwahrscheinlich.
Ich grübele schon die ganze Zeit was diesen Crash tatsächlich verursacht hat - hat dieses eine Postfach wirklich den ganzen Exchangeserver lahm gelegt?
Dazu müsste man schon wissen was genau passiert ist und was in den logfiles genau stand/steht.
die Postfächer kann man ja einfach in eine neue „saubere“ dB migrieren, wenn man den Platz hat. ;) ne Sache von überschaubarer Komplexität.
Oder hat veeam auf dem Exchange etwas kaputt gemacht, weil der Veeam-Job für den Exchange nicht richtig eingestellt war oder veeam das Ganze beim kopieren vorher vielleicht nicht in einen ordentlichen State gebracht haben könnte?
Unwahrscheinlich.
Hallo norbertfe,
vielen Dank für deine Einschätzung und Anteilnahme zu diesem Post.
MfG