7
Exchange 2016 Datenbank im Dirty Shutdown
Hallo zusammen,
mir ist vorhin ein folgenschwerer Fehler unterlaufen.
Aufgrund von Platzmangel habe ich die ganzen E*.log Dateien gelöscht, da die Festplatte vollgelaufen war, wo die Datenbank liegt.
Leider habe ich in der Hektik vergessen, die Datenbank-Einbindung aufzuheben und den Informationsspeicher zu stoppen, um die Datenbank in den "clean shutdown"-Status zu versetzen.
Ich habe schon mit esetutil /p versucht die Datenbank wiederherzustellen, nur leider schlägt die Recovery der Datenbank bei dem Schritt "Repairing damaged Tables" fehl, indem Windows einen Appcrash bei eseutil meldet.
Aktuell versuche ich die gelöschten E*.log Dateien wiederherzustellen, aber ich mache mir keine allzugroßen Hoffnungen, da es kein Backup und keine Schattenkopie gibt. (ja, ich weiß, schwerer Fehler :/)
Hat jemand einen Denkanstoß, wie ich die Datenbank wieder funktionsfähig bekomme?
Danke euch
LG
Philipp
---
Die Systeminformationen:
Windows Server 2012 R2
Exchange 2016 CU2
Datenbankgröße: ca. 15 GB
mir ist vorhin ein folgenschwerer Fehler unterlaufen.
Aufgrund von Platzmangel habe ich die ganzen E*.log Dateien gelöscht, da die Festplatte vollgelaufen war, wo die Datenbank liegt.
Leider habe ich in der Hektik vergessen, die Datenbank-Einbindung aufzuheben und den Informationsspeicher zu stoppen, um die Datenbank in den "clean shutdown"-Status zu versetzen.
Ich habe schon mit esetutil /p versucht die Datenbank wiederherzustellen, nur leider schlägt die Recovery der Datenbank bei dem Schritt "Repairing damaged Tables" fehl, indem Windows einen Appcrash bei eseutil meldet.
Aktuell versuche ich die gelöschten E*.log Dateien wiederherzustellen, aber ich mache mir keine allzugroßen Hoffnungen, da es kein Backup und keine Schattenkopie gibt. (ja, ich weiß, schwerer Fehler :/)
Hat jemand einen Denkanstoß, wie ich die Datenbank wieder funktionsfähig bekomme?
Danke euch
LG
Philipp
---
Die Systeminformationen:
Windows Server 2012 R2
Exchange 2016 CU2
Datenbankgröße: ca. 15 GB
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: 364893
Url: https://administrator.de/forum/exchange-2016-datenbank-im-dirty-shutdown-364893.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo..
mir ist vorhin ein folgenschwerer Fehler unterlaufen.
UPS...
Aufgrund von Platzmangel habe ich die ganzen E*.log Dateien gelöscht, da die Festplatte vollgelaufen war, wo die Datenbank liegt.
das ist kein Fehler, sondern schlicht blödheit... sorry, war nicht persönlich gemeint!!!
Leider habe ich in der Hektik vergessen, die Datenbank-Einbindung aufzuheben und den Informationsspeicher zu stoppen, um die Datenbank in den "clean shutdown"-Status zu versetzen.
aha...
Ich habe schon mit esetutil /p versucht die Datenbank wiederherzustellen, nur leider schlägt die Recovery der Datenbank bei dem Schritt "Repairing damaged Tables" fehl, indem Windows einen Appcrash bei eseutil meldet.
hm..
Aktuell versuche ich die gelöschten E*.log Dateien wiederherzustellen, aber ich mache mir keine allzugroßen Hoffnungen, da es kein Backup und keine Schattenkopie gibt. (ja, ich weiß, schwerer Fehler :/)
du gehörst ja ausgepeitscht.... alter verwalter... Schattenkopien sind kein Backup...
kein Backup ist.... doof....
was ,macht der geneigte admin vor der arbeit... richtig eine Datensicherung... und was noch... richtig die gleiche prüfen...
Hat jemand einen Denkanstoß, wie ich die Datenbank wieder funktionsfähig bekomme?
ja.. wenn du magst, mach ich dir ein Angebot...
bitte hör auf zu fummeln.. du machst mehr falsch als heile...
Danke euch
LG
Philipp
---
Die Systeminformationen:
Windows Server 2012 R2
Exchange 2016 CU2
Datenbankgröße: ca. 15 GB
Frank
mir ist vorhin ein folgenschwerer Fehler unterlaufen.
Aufgrund von Platzmangel habe ich die ganzen E*.log Dateien gelöscht, da die Festplatte vollgelaufen war, wo die Datenbank liegt.
Leider habe ich in der Hektik vergessen, die Datenbank-Einbindung aufzuheben und den Informationsspeicher zu stoppen, um die Datenbank in den "clean shutdown"-Status zu versetzen.
Ich habe schon mit esetutil /p versucht die Datenbank wiederherzustellen, nur leider schlägt die Recovery der Datenbank bei dem Schritt "Repairing damaged Tables" fehl, indem Windows einen Appcrash bei eseutil meldet.
Aktuell versuche ich die gelöschten E*.log Dateien wiederherzustellen, aber ich mache mir keine allzugroßen Hoffnungen, da es kein Backup und keine Schattenkopie gibt. (ja, ich weiß, schwerer Fehler :/)
kein Backup ist.... doof....
was ,macht der geneigte admin vor der arbeit... richtig eine Datensicherung... und was noch... richtig die gleiche prüfen...
Hat jemand einen Denkanstoß, wie ich die Datenbank wieder funktionsfähig bekomme?
bitte hör auf zu fummeln.. du machst mehr falsch als heile...
Danke euch
LG
Philipp
---
Die Systeminformationen:
Windows Server 2012 R2
Exchange 2016 CU2
Datenbankgröße: ca. 15 GB
Also ich würde auch jemanden daran lassen, der weiß was er tut. Aber ich bin keiner der darüber Urteilt.
Versuche es mal hiermit:
https://technet.microsoft.com/en-us/library/ee332351(v=exchg.160).aspx
Versuche es mal hiermit:
https://technet.microsoft.com/en-us/library/ee332351(v=exchg.160).aspx
Ist das ein Unternehmen? Wenn ja, ruf Microsoft an und bezahl 500€ und lass die das beheben, dann hat die Firma keinen kritischen Verlust.
Das mit dem Löschen der .log-Dateien ist wohl ziemlich das dümmste was man machen kann. Sorry, aber das war wohl ein riesen Fehler....
Das mit dem Löschen der .log-Dateien ist wohl ziemlich das dümmste was man machen kann. Sorry, aber das war wohl ein riesen Fehler....
Zitat von @vBurak:
Ist das ein Unternehmen? Wenn ja, ruf Microsoft an und bezahl 500€ und lass die das beheben, dann hat die Firma keinen kritischen Verlust.
Das mit dem Löschen der .log-Dateien ist wohl ziemlich das dümmste was man machen kann. Sorry, aber das war wohl ein riesen Fehler....
Ist das ein Unternehmen? Wenn ja, ruf Microsoft an und bezahl 500€ und lass die das beheben, dann hat die Firma keinen kritischen Verlust.
Das mit dem Löschen der .log-Dateien ist wohl ziemlich das dümmste was man machen kann. Sorry, aber das war wohl ein riesen Fehler....
so günstig gibt sich MS dafür her?
Nunja, ich schliesse mich Frank an, kannst gerne schreiben, aber eine Garantie gibt dir wohl keiner.
Ich kannte, dass immer als "Call Microsoft and pay $500". In Deutschland ist es wohl sogar günstiger:
https://support.microsoft.com/de-de/gp/offerprophone
Weiß aber nicht, ob die auch helfen, wenn die Umgebung unsupportet ist, z.B. Exchange auf einem DC.
https://support.microsoft.com/de-de/gp/offerprophone
Weiß aber nicht, ob die auch helfen, wenn die Umgebung unsupportet ist, z.B. Exchange auf einem DC.
und...
Obwohl sich unsere Supportexperten nach besten Kräften um die Lösung Ihres Problems bemühen, kann Microsoft aufgrund der Vielfalt der Computerkonfigurationen unsere Benutzer nicht garantieren, dass alle Probleme gelöst werden. Der Kunde kann anfordern, dass ein Fall vor seiner Lösung abgeschlossen wird, allerdings liegt die Abrechnung im Ermessen von Microsoft.
Ich denke, aufgrund der genannten Frickelei wird MS nicht sagen 600€ und gut
Obwohl sich unsere Supportexperten nach besten Kräften um die Lösung Ihres Problems bemühen, kann Microsoft aufgrund der Vielfalt der Computerkonfigurationen unsere Benutzer nicht garantieren, dass alle Probleme gelöst werden. Der Kunde kann anfordern, dass ein Fall vor seiner Lösung abgeschlossen wird, allerdings liegt die Abrechnung im Ermessen von Microsoft.
Ich denke, aufgrund der genannten Frickelei wird MS nicht sagen 600€ und gut
Moin,
Am sichersten wäre es sicherlich, wenn du vom System ein Image ziehst (Server herunterfahren, Image ziehen, hochfahren) und das Image dann in einer Testumgebung einspielen. Dann an der Testumgebung mal schauen, wie du wieder an ein funktionsfähiges System kommst. Das dann testen (mehrere Stunden/ Tage). Wenn das Testsystem dann weiterhin stabil lauft, nochmal nen Image vom defekten System ziehen und dann das, was du für deinen Erfolg am Testsystem gemacht hast, auf das Originalsystem anwenden.
Beim WAS du tun musst, habe ich derweil aber keine Idee...
Gruß
em-pie
Am sichersten wäre es sicherlich, wenn du vom System ein Image ziehst (Server herunterfahren, Image ziehen, hochfahren) und das Image dann in einer Testumgebung einspielen. Dann an der Testumgebung mal schauen, wie du wieder an ein funktionsfähiges System kommst. Das dann testen (mehrere Stunden/ Tage). Wenn das Testsystem dann weiterhin stabil lauft, nochmal nen Image vom defekten System ziehen und dann das, was du für deinen Erfolg am Testsystem gemacht hast, auf das Originalsystem anwenden.
Beim WAS du tun musst, habe ich derweil aber keine Idee...
Gruß
em-pie
