2
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.01.2025 um 00:01 Uhr
2 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. 
