10
Nach Veeam-Backup: Failed ExchangeDB kann nicht "resumed" werden
Hallo zusammen und direkt einmal Entschuldigung für den Titel, aber ich wusste nicht, wie ich das Problem kurz und knapp zusammenfassen soll.
Ich beschreibe es euch besser detailliert:
Folgendes Scenario:
Bei uns laufen 3 Exchange 2019 Server als DAG mit 9 Datenbanken.
Die Datenbanken werden abwechselnd auf Server 1&2 aktiv bzw. passiv gemountet, Server 3 ist ein rein passiver Knoten. Also wiefolgt:
DB1/Server1 Aktiv - DB1/Server2 Passiv - DB1/Server3 Passiv
DB2/Server1 Passiv - DB2/Server2 Aktiv - DB2/Server3 Passiv
etc.
Umlaufprotokollierung ist aktiviert.
Das Ganze wird via Veeam Backup&Recovery gesichert, hier sind alle 3 Server in einem Backup-Job mit Anwendungserkennung eingerichtet (Truncate LOGS).
Bis vor kurzem hat das auch einwandfrei funktioniert.
Seit letzter Woche gehen bei dem Backup-Job zwischen 1 und 4 passive Datenbanken in den Status "Failed and Suspended" mit der Meldung es gäbe eine FileSystemCorruption.
Soweit so klar, nur kann es laut MS bei ReFS formatierten Datenträgern keine Corruption geben
Wenn ich dann also mit ESEUTIL das Soft-Repair durchführe, kann ich die Datenbanken problemlos reparieren und sie wechseln dann den Status von "Dirty Shutdown" in "Clean Shutdown"
Allerdings Kann ich im Anschluss die Datenbank nicht resumen, weil als Grund für den Shutdown immernoch "FileSystemCorruption" drin steht.
Ich muss die DBs dann Reseeden, was aber pro DB lockere 2h dauert....
Und nun meine Frage:
Weiß jemand, wie ich die Datenbanken trotzdem resumen kann? Gibts irgendwo einen FORCE Schalter o.ä.? Habe dazu leider nichts gefunden
Und ja, ich bin natürlich dabei, den eigentlichen Grund zu finden, warum das passiert, ich vermute die DBs sind einfach zu groß, denn das einzige was geändert wurde war, die Volumes der DBs zu erweitern weil sie halt zu groß wurden.
Vermutlich wäre es dann jetzt bei uns sinnvoller nur den passiven Node zu sichern, dann hätte ich ja die DBs auch dabei, ohne die aktiven Nodes zu belasten...
Falls jemand bis hierher durchgehalten hat: VIELEN DANK!
TLDR:
Passive Exchange-DBs in 2019DAG nach Veeam Backup in Failed&Suspended.
Softrepair erfolgreich, Resume nicht möglich wegen angeblicher FileSystemCorruption.
Benötige Idee um Resume doch noch machen zu können
Ich beschreibe es euch besser detailliert:
Folgendes Scenario:
Bei uns laufen 3 Exchange 2019 Server als DAG mit 9 Datenbanken.
Die Datenbanken werden abwechselnd auf Server 1&2 aktiv bzw. passiv gemountet, Server 3 ist ein rein passiver Knoten. Also wiefolgt:
DB1/Server1 Aktiv - DB1/Server2 Passiv - DB1/Server3 Passiv
DB2/Server1 Passiv - DB2/Server2 Aktiv - DB2/Server3 Passiv
etc.
Umlaufprotokollierung ist aktiviert.
Das Ganze wird via Veeam Backup&Recovery gesichert, hier sind alle 3 Server in einem Backup-Job mit Anwendungserkennung eingerichtet (Truncate LOGS).
Bis vor kurzem hat das auch einwandfrei funktioniert.
Seit letzter Woche gehen bei dem Backup-Job zwischen 1 und 4 passive Datenbanken in den Status "Failed and Suspended" mit der Meldung es gäbe eine FileSystemCorruption.
Soweit so klar, nur kann es laut MS bei ReFS formatierten Datenträgern keine Corruption geben
Wenn ich dann also mit ESEUTIL das Soft-Repair durchführe, kann ich die Datenbanken problemlos reparieren und sie wechseln dann den Status von "Dirty Shutdown" in "Clean Shutdown"
Allerdings Kann ich im Anschluss die Datenbank nicht resumen, weil als Grund für den Shutdown immernoch "FileSystemCorruption" drin steht.
Ich muss die DBs dann Reseeden, was aber pro DB lockere 2h dauert....
Und nun meine Frage:
Weiß jemand, wie ich die Datenbanken trotzdem resumen kann? Gibts irgendwo einen FORCE Schalter o.ä.? Habe dazu leider nichts gefunden
Und ja, ich bin natürlich dabei, den eigentlichen Grund zu finden, warum das passiert, ich vermute die DBs sind einfach zu groß, denn das einzige was geändert wurde war, die Volumes der DBs zu erweitern weil sie halt zu groß wurden.
Vermutlich wäre es dann jetzt bei uns sinnvoller nur den passiven Node zu sichern, dann hätte ich ja die DBs auch dabei, ohne die aktiven Nodes zu belasten...
Falls jemand bis hierher durchgehalten hat: VIELEN DANK!
TLDR:
Passive Exchange-DBs in 2019DAG nach Veeam Backup in Failed&Suspended.
Softrepair erfolgreich, Resume nicht möglich wegen angeblicher FileSystemCorruption.
Benötige Idee um Resume doch noch machen zu können
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670955
Url: https://administrator.de/forum/nach-veeam-backup-failed-exchangedb-kann-nicht-resumed-werden-670955.html
Ausgedruckt am: 25.02.2025 um 23:02 Uhr
10 Kommentare
Neuester Kommentar
Moin...
hm... das Problem ist mir schon mal mit ReFS über die Füße gelaufen!
wie groß sind die DBs?
schon mal an einen wechsel zu ntfs gedacht?
was sagt ein:
Frank
hm... das Problem ist mir schon mal mit ReFS über die Füße gelaufen!
wie groß sind die DBs?
schon mal an einen wechsel zu ntfs gedacht?
was sagt ein:
Get-MailboxDatabaseCopyStatus * | sort name | Select name,status,contentindexstateFrank
Die Datenbanken sind dann im Status "FailedandSuspended".
ESEUTIL /mh zeigt: State: DirtyShutdown
Ich kann dann Softrepair mittels ESEUTIL /r durchführen, dann wechselt der Status in CleanShutdown
Wenn ich dann versuche die DB mittels Resume-MailboxDatabaseCopy wieder anzustarten, bekomme ich folgende Fehlermeldung:
ESEUTIL /mh zeigt: State: DirtyShutdown
Ich kann dann Softrepair mittels ESEUTIL /r durchführen, dann wechselt der Status in CleanShutdown
Wenn ich dann versuche die DB mittels Resume-MailboxDatabaseCopy wieder anzustarten, bekomme ich folgende Fehlermeldung:
Fehler bei einem serverseitigen Verwaltungsvorgang. Für die Datenbankkopie war keine Fortsetzung möglich, da ein vorheriger Fehler den Fortsetzungsvorgang verhindert. Fehler: At '24.01.2025 11:10::20' the Exchange store database 'DB6' copy on this server detected file system corruption. For more details about the failure, consult the Event log on the server for other storage and "ExchangeStoreDb" events. The passive database copy has been suspended.
Moin...
was sagt den dein Event Log dazu, und wie groß sind nun die DBs?
ist der exchange aktuell?
was sagt der veeam support dazu?
was passiert, wenn du mit der windows sicherung ein backup machst?
storage schon überprüft auf schäden?
How to Use PowerShell to Fix Corruption on ReFS Volumes
frank
was sagt den dein Event Log dazu, und wie groß sind nun die DBs?
ist der exchange aktuell?
was sagt der veeam support dazu?
was passiert, wenn du mit der windows sicherung ein backup machst?
storage schon überprüft auf schäden?
Soweit so klar, nur kann es laut MS bei ReFS formatierten Datenträgern keine Corruption geben face-smile
glaubst du...How to Use PowerShell to Fix Corruption on ReFS Volumes
Das Ganze wird via Veeam Backup&Recovery gesichert, hier sind alle 3 Server in einem Backup-Job mit Anwendungserkennung eingerichtet (Truncate LOGS).
hast du schon versucht die 3 exchange einzeln zu sichern? etc. ?frank
Welche Emailarchivierung wird verwendet? (um die EDBs klein zu halten) (kann Ausnahmesweise mehr archiviert werden, damit die EDBs kleiner werden) Wäre Migra in neue EDB nicht ggf. naheliegend.
ReFS ist keine Garantie dafür, dass keine d
Dateifehler auftreten. Fehler können zwar entdeckt werden, aber zur Reparatur benötigt es Storage Spaces Direct. Davon abgesehen können Dateien beschädigt werden, ohne dass ein Filesystem Fehler vorliegt. Und für Exchange Datenbanken sollte Integrity sogar deaktiviert werden ;)
Ich habe alle Exchange weiterhin mit NTFS betrieben.
Das von dir beschriebene Problem hätte ich im Zusammenhang mit Veeam noch nicht gesehen. Während der Sicherung könnte es zu einem Failover kommem, abhängig von der Last und wie eure Sicherung eingerichtet ist. Habt ihr einen Job für alle Exchange Server und werden diese parallel gesichert?
Ggf. mal den Best Practice Guide und den erwähnten KB Artikel prüfen.
https://bp.veeam.com/vbr/4_Operations/O_Application/exchange.html
Dateifehler auftreten. Fehler können zwar entdeckt werden, aber zur Reparatur benötigt es Storage Spaces Direct. Davon abgesehen können Dateien beschädigt werden, ohne dass ein Filesystem Fehler vorliegt. Und für Exchange Datenbanken sollte Integrity sogar deaktiviert werden ;)
Ich habe alle Exchange weiterhin mit NTFS betrieben.
Das von dir beschriebene Problem hätte ich im Zusammenhang mit Veeam noch nicht gesehen. Während der Sicherung könnte es zu einem Failover kommem, abhängig von der Last und wie eure Sicherung eingerichtet ist. Habt ihr einen Job für alle Exchange Server und werden diese parallel gesichert?
Ggf. mal den Best Practice Guide und den erwähnten KB Artikel prüfen.
https://bp.veeam.com/vbr/4_Operations/O_Application/exchange.html
Hallo zusammen,
vielen Dank für eure Antworten bisher. Da der ganze Vorgang noch recht frisch ist, habe ich natürlich noch nicht alle Möglichkeiten ausprobiert.
Ich gehe aber auch nicht davon aus, dass etwas grundsätzlich falsch läuft, da die einzige Veränderung wirklich die Erweiterung der Laufwerke für die DBs war.
Ich versuche eure Fragen jetzt so gut es geht zu beantworten:
Das Event-Log spuckt mir folgendes zurück:
Bisher noch nicht, der plan ist aber Umzustellen und erst einmal nur den passiven Node zu sichern.
Wir nutzen EnterpriseVault. Eine Änderung hier müsste ich zuerst abstimmen. Weiß aber auch nicht ob das sinn macht. Müsste ich dann nicht die EDBs händisch schrumpfen?
Neue EDBs zusätzlich erstellen ist natürlich eine Option. Wäre aber unschön.
Wie gesagt, werde ich heute das Backup umstellen, so dass nur der passive Knoten gesichert wird.
vielen Dank für eure Antworten bisher. Da der ganze Vorgang noch recht frisch ist, habe ich natürlich noch nicht alle Möglichkeiten ausprobiert.
Ich gehe aber auch nicht davon aus, dass etwas grundsätzlich falsch läuft, da die einzige Veränderung wirklich die Erweiterung der Laufwerke für die DBs war.
Ich versuche eure Fragen jetzt so gut es geht zu beantworten:
Das Event-Log spuckt mir folgendes zurück:
Zunächst ein MSExchangeRepl 2153:
The log copier was unable to communicate with server 'ExchangeServer1'. The copy of database 'Datenbank2' is in a disconnected state. The communication error was: Fehler beim Kommunizieren mit dem Server 'ExchangeServer1'. Fehler: In die Übertragungsverbindung können keine Daten geschrieben werden: Eine bestehende Verbindung wurde softwaregesteuert
durch den Hostcomputer abgebrochen. The copier will automatically retry after a short delay.Dann ca. 10 Minuten später: Warnung MSExchangeRepl 2138:
Log truncation failed to delete local logs for database 'Datenbank2'. Error: Fehler beim lokalen Abschneiden von Protokolldateien. Hresult: 0x80131500. Fehler: Fehler beim Löschen der Datei oder des Verzeichnisses "J:\LOG\Datenbank2\E02000BDF40.log" in einer Art, die mit einer Beschädigung des Dateisystems konsistent ist. Die empfohlene Aktion besteht darin, das Volume neu zu formatieren. Interner Fehlercode: 0. Darauf folgt zugleich ESE(ESE) 3013:
Information Store - Datenbank2: Im System treten Speicherbelegungsfehler auf, die verhindern, dass die Datenbank 'Datenbank2' ('4301b612-8aba-4df0-8472-5d2d06d63353') ordnungsgemäß ausgeführt wird. Ursache dieses Fehlers ist eine fehlerhafte Konfiguration oder eine übermäßige Arbeitsspeichernutzung auf dem Computer. Und schließlich zum Abschluss ExchangeStoreDB 151:
At '24.01.2025 14:15:20' the Exchange store database 'Datenbank2' copy on this server detected file system corruption. For more details about the failure, consult the Event log on the server for other storage and "ExchangeStoreDb" events. The passive database copy has been suspended. Und ExchangeStoreDB 121:
At '24.01.2025 14:15:20' the Exchange store database 'Datenbank2' copy on this server appears to have failed due to insufficient memory. For more details about the failure, consult the Event log on the server for other "ExchangeStoreDb" events. Recovery was not attempted. und wie groß sind nun die DBs?
Die DBs sind zwischen 230 und 350GB groß.ist der exchange aktuell?
Ja, bis auf die Januar-Patche. Die sind noch nicht eingepielt.was sagt der veeam support dazu?
Ist kontaktiert, warte auf Rückmeldungwas passiert, wenn du mit der windows sicherung ein backup machst?
Kann ich leider nicht testen.storage schon überprüft auf schäden?
Storage zeigt keinerlei Fehler an. Wenn ich die Datenbank Reseede läuft auch alles wunderbar, bis zum nächsten Sicherungsvorgang (es sind auch nicht notwendigerweise immer die gleichen Datenbanken die dann ausfallen... aber interessanterweise (und glücklicherweise) bisher immer nur die passiven Kopien.Das Ganze wird via Veeam Backup&Recovery gesichert, hier sind alle 3 Server in einem Backup-Job mit Anwendungserkennung eingerichtet (Truncate LOGS).
hast du schon versucht die 3 exchange einzeln zu sichern? etc. ?Zitat von @ManuManu2021:
Welche Emailarchivierung wird verwendet? (um die EDBs klein zu halten) (kann Ausnahmesweise mehr archiviert werden, damit die EDBs kleiner werden) Wäre Migra in neue EDB nicht ggf. naheliegend.
Welche Emailarchivierung wird verwendet? (um die EDBs klein zu halten) (kann Ausnahmesweise mehr archiviert werden, damit die EDBs kleiner werden) Wäre Migra in neue EDB nicht ggf. naheliegend.
Wir nutzen EnterpriseVault. Eine Änderung hier müsste ich zuerst abstimmen. Weiß aber auch nicht ob das sinn macht. Müsste ich dann nicht die EDBs händisch schrumpfen?
Neue EDBs zusätzlich erstellen ist natürlich eine Option. Wäre aber unschön.
Zitat von @regnor:
ReFS ist keine Garantie dafür, dass keine d
Dateifehler auftreten. Fehler können zwar entdeckt werden, aber zur Reparatur benötigt es Storage Spaces Direct. Davon abgesehen können Dateien beschädigt werden, ohne dass ein Filesystem Fehler vorliegt. Und für Exchange Datenbanken sollte Integrity sogar deaktiviert werden ;)
Ja, ich habe das inzwischen gelesen. Hilft mir leider jetzt alles nix mehr ReFS ist keine Garantie dafür, dass keine d
Dateifehler auftreten. Fehler können zwar entdeckt werden, aber zur Reparatur benötigt es Storage Spaces Direct. Davon abgesehen können Dateien beschädigt werden, ohne dass ein Filesystem Fehler vorliegt. Und für Exchange Datenbanken sollte Integrity sogar deaktiviert werden ;)
Ich habe alle Exchange weiterhin mit NTFS betrieben.
Dazu habe ich tatsächlich auch einiges gelesen. Wäre natürlich sehr schade, da wir erst vor nem halben Jahr oder so auf ReFS umgestellt haben.Das von dir beschriebene Problem hätte ich im Zusammenhang mit Veeam noch nicht gesehen. Während der Sicherung könnte es zu einem Failover kommem, abhängig von der Last und wie eure Sicherung eingerichtet ist.
Ich vermute auch, dass nach der letzten Erweiterung die Datenmenge einfach zu groß ist, dass es im Hintergrund in einen Timeout läuft und dann Failover oder so...Habt ihr einen Job für alle Exchange Server und werden diese parallel gesichert?
Ja, einen für alle. Noch.Ggf. mal den Best Practice Guide und den erwähnten KB Artikel prüfen.
https://bp.veeam.com/vbr/4_Operations/O_Application/exchange.html
Danke für den Link.https://bp.veeam.com/vbr/4_Operations/O_Application/exchange.html
Wie gesagt, werde ich heute das Backup umstellen, so dass nur der passive Knoten gesichert wird.
Hallo zusammen,
ich habe heute den Veeam Job umgestellt, so dass nur noch der Passive Node gesichert wird.
Damit lief zumindest die erste Sicherung wieder fehlerfrei durch, ohne dass die Datenbanken korrumpiert wurden.
In den LOGs der anderen Server habe ich noch zahlreiche Hinweise darauf gefunden, dass den Servern der Speicher voll läuft (haben derzeit 32GB RAM & 8GB Auslagerungsdatei).
Bin jetzt erstmal am Klären ob wir die Hosts auf 64GB RAM / 16GB Auslagerung erweitern können.
ich habe heute den Veeam Job umgestellt, so dass nur noch der Passive Node gesichert wird.
Damit lief zumindest die erste Sicherung wieder fehlerfrei durch, ohne dass die Datenbanken korrumpiert wurden.
In den LOGs der anderen Server habe ich noch zahlreiche Hinweise darauf gefunden, dass den Servern der Speicher voll läuft (haben derzeit 32GB RAM & 8GB Auslagerungsdatei).
Bin jetzt erstmal am Klären ob wir die Hosts auf 64GB RAM / 16GB Auslagerung erweitern können.
Auslagerungsdatei?
Meinst pagefile.sys?
falls ja sollte die mindestens gleichgross sein wie der RAM, nur so als anmerkung....
Meinst pagefile.sys?
falls ja sollte die mindestens gleichgross sein wie der RAM, nur so als anmerkung....
Zitat von @ThePinky777:
Auslagerungsdatei?
Meinst pagefile.sys?
falls ja sollte die mindestens gleichgross sein wie der RAM, nur so als anmerkung....
Auslagerungsdatei?
Meinst pagefile.sys?
falls ja sollte die mindestens gleichgross sein wie der RAM, nur so als anmerkung....
Ja Pagefile.
Und nein, Microsoft sagt:
Set the paging file minimum and maximum value to the same size: 25% of installed memory.Quelle:
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/system-requir ...
Hallo zusammen,
um das ganze kurz aufzulösen:
Nachdem wir unsere Exchange-Server von 32 auf 64GB RAM und auch das Swapfile entsprechend erweitert hatten, lief die Sicherung wieder wie gewohnt durch.
Anscheinend wurde hier tatsächlich eine Grenze erreicht, so dass der vorhandene Speicher zu einem Abbruch geführt hat.
Danke für eure rege Beteiligung!
um das ganze kurz aufzulösen:
Nachdem wir unsere Exchange-Server von 32 auf 64GB RAM und auch das Swapfile entsprechend erweitert hatten, lief die Sicherung wieder wie gewohnt durch.
Anscheinend wurde hier tatsächlich eine Grenze erreicht, so dass der vorhandene Speicher zu einem Abbruch geführt hat.
Danke für eure rege Beteiligung!
