5
Exchange 2000 defekte Sektoren auf Festplatte im Bereich der Maildatenbank priv1.edb
Hallo,
die Festplatte unseres Mail-Servers (Windows 2000 Server SP4, Exchange 2000 Standard SP3) hat im Bereich der Maildatenbank priv1.edb defekte Sektoren aufgewiesen, allerdings wohl in momentan ungenutzten Bereichen, da die Sicherung der einzelnen Postfächer mit Veritas Backup Exec 10.0 per Exchange Remote Agent ohne Fehler funktioniert hat, aber nicht die Sicherung der kompletten Speichergruppe.
Ich habe die Partitionen der defekten Festplatte mit dem Programm Drive Snapshot gesichert (dabei wurden 19 defekte Sektoren angezeigt) und auf eine neue (fehlerfreie) Festplatte zurückgespielt. Der Mail-Server läuft nun auch wieder, allerdings sind nach wie vor die Fehler im Dateisystem von den ehemals defekten Sektoren vorhanden. Auch bei der Sicherung hat sich nichts verändert, sprich: Sicherung der Postfächer ohne Probleme, Sicherung der kompletten Speichergruppe schlägt fehl.
Die Frage ist nun: wie gehe ich am besten vor, um wieder eine voll funktionsfähige Maildatenbank zu erhalten?
Meine Überlegungen dazu:
- CHKDSK starten und Dateisystemfehler korrigieren lassen? Habe hierbei Angst davor, dass dadurch die komplette priv1.edb verworfen oder irgendwie unbrauchbar werden könnte
- Offline-Defragmentierung der Maildatenbank durchführen? Geht das überhaupt, solange noch Fehler im Dateisystem vorhanden sind?
- Was kann ich tun, um mögliche Probleme bei den nun nötigen Schritten vorab zu erkennen (z.B. Einsatz von ESEUTIL etc.?) und zu umgehen?
Wie gesagt, die Festplatte selbst sollte wieder fehlerfrei sein, die Daten der kopierten defekten Sektoren sind wohl in irgendeiner Form korrupt, aber die derzeit genutzten Bereiche in der Maildatenbank scheinen davon nicht betroffen zu sein.
Bin für jede Hilfe dankbar!
Gruß,
Hubert.
die Festplatte unseres Mail-Servers (Windows 2000 Server SP4, Exchange 2000 Standard SP3) hat im Bereich der Maildatenbank priv1.edb defekte Sektoren aufgewiesen, allerdings wohl in momentan ungenutzten Bereichen, da die Sicherung der einzelnen Postfächer mit Veritas Backup Exec 10.0 per Exchange Remote Agent ohne Fehler funktioniert hat, aber nicht die Sicherung der kompletten Speichergruppe.
Ich habe die Partitionen der defekten Festplatte mit dem Programm Drive Snapshot gesichert (dabei wurden 19 defekte Sektoren angezeigt) und auf eine neue (fehlerfreie) Festplatte zurückgespielt. Der Mail-Server läuft nun auch wieder, allerdings sind nach wie vor die Fehler im Dateisystem von den ehemals defekten Sektoren vorhanden. Auch bei der Sicherung hat sich nichts verändert, sprich: Sicherung der Postfächer ohne Probleme, Sicherung der kompletten Speichergruppe schlägt fehl.
Die Frage ist nun: wie gehe ich am besten vor, um wieder eine voll funktionsfähige Maildatenbank zu erhalten?
Meine Überlegungen dazu:
- CHKDSK starten und Dateisystemfehler korrigieren lassen? Habe hierbei Angst davor, dass dadurch die komplette priv1.edb verworfen oder irgendwie unbrauchbar werden könnte
- Offline-Defragmentierung der Maildatenbank durchführen? Geht das überhaupt, solange noch Fehler im Dateisystem vorhanden sind?
- Was kann ich tun, um mögliche Probleme bei den nun nötigen Schritten vorab zu erkennen (z.B. Einsatz von ESEUTIL etc.?) und zu umgehen?
Wie gesagt, die Festplatte selbst sollte wieder fehlerfrei sein, die Daten der kopierten defekten Sektoren sind wohl in irgendeiner Form korrupt, aber die derzeit genutzten Bereiche in der Maildatenbank scheinen davon nicht betroffen zu sein.
Bin für jede Hilfe dankbar!
Gruß,
Hubert.
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: 114406
Url: https://administrator.de/contentid/114406
Ausgedruckt am: 19.11.2024 um 20:11 Uhr
5 Kommentare
Neuester Kommentar
Was du suchst findest du hier :
http://www.msxfaq.de/notfall/desaster2k.htm
und hier:
http://www.msxfaq.de/notfall/korrupt.htm
Wenn das nicht hilft, dann wäre es eine Überlegung wert ob man die Datenbank priv1.edb und priv1.stm nicht löscht, und neu anlegt.
Dazu müstest du vorher die Postfächer alle exportieren um sie danach wieder importieren zu können in die neue Datenbank.
Seit wann gibt es die defekten Sektoren?
Hast du noch eine Backup Sicherung die eine nicht korrupte Exch Datenbank beinhalten ?
Wenn ja Postfächer Exportieren, Datenbank von der Sicherung wiederherstellen und die Postfächer wieder importieren.
http://www.msxfaq.de/notfall/desaster2k.htm
und hier:
http://www.msxfaq.de/notfall/korrupt.htm
Wenn das nicht hilft, dann wäre es eine Überlegung wert ob man die Datenbank priv1.edb und priv1.stm nicht löscht, und neu anlegt.
Dazu müstest du vorher die Postfächer alle exportieren um sie danach wieder importieren zu können in die neue Datenbank.
Seit wann gibt es die defekten Sektoren?
Hast du noch eine Backup Sicherung die eine nicht korrupte Exch Datenbank beinhalten ?
Wenn ja Postfächer Exportieren, Datenbank von der Sicherung wiederherstellen und die Postfächer wieder importieren.
Danke erstmal für die Antwort!
Die Seiten von www.msxfaq.de hatte ich mir auch schon angeschaut, allerdings habe ich dort nichts zu der Thematik mit den defekten Sektoren in (wahrscheinlich) ungenutzten Bereichen der Datenbank gefunden.
Die letzte durchgelaufene Sicherung der kompletten Maildatenbank ist schon einige Wochen alt. Aber da die Sicherung der einzelnen Postfächer ohne Fehler durchgelaufen ist, würde ich erst versuchen wollen, den momentanen Stand weiterzuverwenden, falls möglich...
Gibt es irgendwelche Infos bzgl. der Verträglichkeit mit CHKDSK?
Vielleicht sollte ich das Image noch auf eine andere Platte spielen und dann an einem Clientrechner ausprobieren, ob CHKDSK die komplette priv1.edb für ungültig erklärt. Reparaturversuche kann ich ja auch ohne installertes Exchange 2000 machen, wenn ich das BIN-Verzeichnis vom Server kopiere...
Die Seiten von www.msxfaq.de hatte ich mir auch schon angeschaut, allerdings habe ich dort nichts zu der Thematik mit den defekten Sektoren in (wahrscheinlich) ungenutzten Bereichen der Datenbank gefunden.
Die letzte durchgelaufene Sicherung der kompletten Maildatenbank ist schon einige Wochen alt. Aber da die Sicherung der einzelnen Postfächer ohne Fehler durchgelaufen ist, würde ich erst versuchen wollen, den momentanen Stand weiterzuverwenden, falls möglich...
Gibt es irgendwelche Infos bzgl. der Verträglichkeit mit CHKDSK?
Vielleicht sollte ich das Image noch auf eine andere Platte spielen und dann an einem Clientrechner ausprobieren, ob CHKDSK die komplette priv1.edb für ungültig erklärt. Reparaturversuche kann ich ja auch ohne installertes Exchange 2000 machen, wenn ich das BIN-Verzeichnis vom Server kopiere...
Hallo,
CHKDSK überprüft nur die Festplatte und die Sektoren
CHKDSK wird nicht die Exchange Datenbank überprüfen.
ESEUTIL überprüft die Datenbank. Hiermit kann man die Datenbank auch reparieren fall sie Fehler aufweist.
Jetzt ist die Frage. Was suchst du? Etwas was deine defekte Sektoren auf der Platte repariert ? Oder etwas was deine womöglich korupte Exchange Datenbank repariert?
CHKDSK überprüft nur die Festplatte und die Sektoren
CHKDSK wird nicht die Exchange Datenbank überprüfen.
ESEUTIL überprüft die Datenbank. Hiermit kann man die Datenbank auch reparieren fall sie Fehler aufweist.
Jetzt ist die Frage. Was suchst du? Etwas was deine defekte Sektoren auf der Platte repariert ? Oder etwas was deine womöglich korupte Exchange Datenbank repariert?
Ja, das ist mir natürlich klar, dass CHKDSK nur die Festplatte selbst bzw. das Dateisystem überprüft, und dass ESEUTIL nur auf die Datenbank wirkt, auch.
Wie gesagt, die Fehler in der Datenbank sind durch (ehemals) defekte Sektoren der alten Festplatte entstanden und verhindern nach wie vor ein Backup der gesamten Speichergruppe. Die Sicherung aller Postfächer klappt jedoch nach wie vor, deshalb nehme ich an, dass nur nicht mehr benutzte Pages betroffen sind.
Allerdings sind jetzt nach der Imageerstellung und Rückspielung auf die neue fehlerfreie Platte sowohl noch Fehler im Dateisystem vorhanden (deshalb die Frage nach CHKDSK), die behoben werden müssen, und die dadurch verursachten Fehler in der Datenbank müssen natürlich auch noch weg (deshalb ESEUTIL).
Effektiv werde ich wohl beides machen müssen, die Frage ist nur, in welcher Reihenfolge.
Bei CHKDSK habe ich Bedenken, dass beim Reparaturversuch die komplette Datei priv1.edb als "betroffen" und somit defekt angesehen werden könnte und mir dann die immerhin noch lauffähige aktuelle Datenbank abhanden gehen könnte.
Bei einem normalen Kopierversuch der kompletten Datei könnten die korrupten Sektordaten im Dateisystem zu einem CRC-Error o.ä. führen und den Kopiervorgang abbrechen (konnte ich noch nicht ausprobieren, ist aber wohl die risikoloseste Option auf der Platte selbst).
Falls der Kopiervorgang wider Erwarten klappen sollte, könnte ich die Kopie mit dem ESEUTIL bearbeiten, ohne die aktuelle Datenbank selbst in Gefahr zu bringen.
Der Einsatz vom ESEUTIL auf der aktuellen Datenbank (ohne weitere Sicherung) ist mir eigentlich zu riskant, insbesondere wegen der noch vorhandenen Fehler im Dateisystem...
Sorry, ich hoffe, Du verstehst mein Dilemma.
Falls CHKDSK die Datei priv1.edb bei der Reparatur des Dateisystems nicht zerstören sollte, würde ich zuerst CHKDSK anwenden, dann die DB kopieren und die Kopie dann mit ESEUTIL reparieren. Aber ob dem so ist, weiss ich halt nicht...
Wie gesagt, die Fehler in der Datenbank sind durch (ehemals) defekte Sektoren der alten Festplatte entstanden und verhindern nach wie vor ein Backup der gesamten Speichergruppe. Die Sicherung aller Postfächer klappt jedoch nach wie vor, deshalb nehme ich an, dass nur nicht mehr benutzte Pages betroffen sind.
Allerdings sind jetzt nach der Imageerstellung und Rückspielung auf die neue fehlerfreie Platte sowohl noch Fehler im Dateisystem vorhanden (deshalb die Frage nach CHKDSK), die behoben werden müssen, und die dadurch verursachten Fehler in der Datenbank müssen natürlich auch noch weg (deshalb ESEUTIL).
Effektiv werde ich wohl beides machen müssen, die Frage ist nur, in welcher Reihenfolge.
Bei CHKDSK habe ich Bedenken, dass beim Reparaturversuch die komplette Datei priv1.edb als "betroffen" und somit defekt angesehen werden könnte und mir dann die immerhin noch lauffähige aktuelle Datenbank abhanden gehen könnte.
Bei einem normalen Kopierversuch der kompletten Datei könnten die korrupten Sektordaten im Dateisystem zu einem CRC-Error o.ä. führen und den Kopiervorgang abbrechen (konnte ich noch nicht ausprobieren, ist aber wohl die risikoloseste Option auf der Platte selbst).
Falls der Kopiervorgang wider Erwarten klappen sollte, könnte ich die Kopie mit dem ESEUTIL bearbeiten, ohne die aktuelle Datenbank selbst in Gefahr zu bringen.
Der Einsatz vom ESEUTIL auf der aktuellen Datenbank (ohne weitere Sicherung) ist mir eigentlich zu riskant, insbesondere wegen der noch vorhandenen Fehler im Dateisystem...
Sorry, ich hoffe, Du verstehst mein Dilemma.
Falls CHKDSK die Datei priv1.edb bei der Reparatur des Dateisystems nicht zerstören sollte, würde ich zuerst CHKDSK anwenden, dann die DB kopieren und die Kopie dann mit ESEUTIL reparieren. Aber ob dem so ist, weiss ich halt nicht...
Ich verstehe schon dass du bedenken hast.
Die Reihenfolge wäre CHKDSK ausführen. CHKDSK ermittelt defekte Sektoren, versucht die Daten aus diesen Sektoren "rauszukopieren" und auf andere Sektoren abzulegen. Die defekten Sektoren werden gesperrt.
Du hast so oder so eine korrupte Datenbank.
Soweit ich verstanden habe, hast du ja die priv1.edb und priv1.stm schon gesichert. Zumindest die korrupte.
Also immerhin den stand der Datenbank den du jetzt hast.
Um ESEUTIL auszuführen musst du die Datenbank aus dem produktiven Netz nehmen.
Das must du auch bei einem Kopiervorgang auf eine andere Platte.
Du hast ja eine Sicherung, auf der defekten Platte. Wieweit unterscheiden sich den die Platten im Moment ? Also was den Inhalt der Postfächer angeht ?
Führe doch auf der alten Platte ein CHKDSK durch und dann auf der alten Datenbank das ESEUTIL aus.
Da hast du nix zu verlieren. Die ist ja schon defekt.
Wenn ESEUTIL nichts bringt, dann wäre der schnellste und sicherste weg, die Datenbank neu anzulegen.
Vorher natürlich die Postfächer exportieren.
Die Reihenfolge wäre CHKDSK ausführen. CHKDSK ermittelt defekte Sektoren, versucht die Daten aus diesen Sektoren "rauszukopieren" und auf andere Sektoren abzulegen. Die defekten Sektoren werden gesperrt.
Du hast so oder so eine korrupte Datenbank.
Allerdings sind jetzt nach der Imageerstellung und Rückspielung auf die neue fehlerfreie Platte sowohl noch Fehler im Dateisystem vorhanden (deshalb die Frage nach CHKDSK), die behoben werden müssen, und die dadurch verursachten Fehler in der Datenbank müssen natürlich auch noch weg (deshalb ESEUTIL).
Soweit ich verstanden habe, hast du ja die priv1.edb und priv1.stm schon gesichert. Zumindest die korrupte.
Also immerhin den stand der Datenbank den du jetzt hast.
Um ESEUTIL auszuführen musst du die Datenbank aus dem produktiven Netz nehmen.
Das must du auch bei einem Kopiervorgang auf eine andere Platte.
Der Einsatz vom ESEUTIL auf der aktuellen Datenbank (ohne weitere Sicherung) ist mir eigentlich zu riskant, insbesondere wegen der noch vorhandenen Fehler im Dateisystem...
Du hast ja eine Sicherung, auf der defekten Platte. Wieweit unterscheiden sich den die Platten im Moment ? Also was den Inhalt der Postfächer angeht ?
Führe doch auf der alten Platte ein CHKDSK durch und dann auf der alten Datenbank das ESEUTIL aus.
Da hast du nix zu verlieren. Die ist ja schon defekt.
Wenn ESEUTIL nichts bringt, dann wäre der schnellste und sicherste weg, die Datenbank neu anzulegen.
Vorher natürlich die Postfächer exportieren.
