3
Exchange Fehler bei Backup ESE 217, 478 (613)
Hallo,
unverhoft kommt manchmal aus dem Nichts....
Heute hat der SBS 2003 eine beunruhigende Fehlermeldung für mich gehabt.
Das Backup mit NTBACKUP lief nicht durch und brahcte ESE 478, 217 Meldungen.
Die pub1.stm ist betroffen.
Und etwas später System Meldungen, das ntfs Probleme hatt und chkdsk ausgeführt werden soll.
Gesichert wird neben BESR auch mit NTBACKUP, die Sicherung mit BESR lief durch.
Mein Plan, Exchange nach Feierabernd stoppen und dann ein chkdisk machen. Und dann mal schauen was NTBACKUP macht.
Hat jemand von Euch schon Erfahrung mit diesem Problem?
Gruß
Chonta
Nachtrag: Die Onlinedefragmentierung der edb Dateien ging normal Durch.
Die ESE 222 Meldung besagt Nicht alle Daten in der Datei konnten gelesen werden (27915059200 Bytes gelesen von 47410323456 Bytes)
Genauer Hergang:
NTBACKUP startet
die pub1.edb wird gesichert.
Dann wird pub1.stm Sicherung gestartet und ca 25 Minuten später tauchen
ESE 478 Fehler auf
Information Store (4612) Fehler bei Überprüfung der aus Datei ....
613 (0xfffffd9b) bei Leseoperation...
Und dann naxh 18 dieser Meldungen die 222er meldung und Backup nicht erstellt von NTBACKUP.
Danach geht alles weiter und um 0:00 Uhr starten die normalen täglichen Wartungsarbeiten. (Keine weiteren Meldungen)
Heute hatte dann ein Benutzer Probleme mit seinem Profil und die NTFS Meldungen kamen im log.
unverhoft kommt manchmal aus dem Nichts....
Heute hat der SBS 2003 eine beunruhigende Fehlermeldung für mich gehabt.
Das Backup mit NTBACKUP lief nicht durch und brahcte ESE 478, 217 Meldungen.
Die pub1.stm ist betroffen.
Und etwas später System Meldungen, das ntfs Probleme hatt und chkdsk ausgeführt werden soll.
Gesichert wird neben BESR auch mit NTBACKUP, die Sicherung mit BESR lief durch.
Mein Plan, Exchange nach Feierabernd stoppen und dann ein chkdisk machen. Und dann mal schauen was NTBACKUP macht.
Hat jemand von Euch schon Erfahrung mit diesem Problem?
Gruß
Chonta
Nachtrag: Die Onlinedefragmentierung der edb Dateien ging normal Durch.
Die ESE 222 Meldung besagt Nicht alle Daten in der Datei konnten gelesen werden (27915059200 Bytes gelesen von 47410323456 Bytes)
Genauer Hergang:
NTBACKUP startet
die pub1.edb wird gesichert.
Dann wird pub1.stm Sicherung gestartet und ca 25 Minuten später tauchen
ESE 478 Fehler auf
Information Store (4612) Fehler bei Überprüfung der aus Datei ....
613 (0xfffffd9b) bei Leseoperation...
Und dann naxh 18 dieser Meldungen die 222er meldung und Backup nicht erstellt von NTBACKUP.
Danach geht alles weiter und um 0:00 Uhr starten die normalen täglichen Wartungsarbeiten. (Keine weiteren Meldungen)
Heute hatte dann ein Benutzer Probleme mit seinem Profil und die NTFS Meldungen kamen im log.
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: 195260
Url: https://administrator.de/contentid/195260
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo Chonta,
ich hatte bei einem Kunden mit SBS 2003 ähnliche Fehler nach einem SP Update.
Kurzgesagt hat mich eseutil /p in der Kommandozeile weiter gebracht.
Hier der Link zum ganzen Artikel:
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exc ...
Ich hoffe ich konnte dir helfen.
PS: Denkst du bitte an ein Server Back-Up? Ich hab hier schon leidvolle Erfahrungen gemacht. Kannst du mittels Acronis o.Ä. tun.
Grüße Lenny Linux
ich hatte bei einem Kunden mit SBS 2003 ähnliche Fehler nach einem SP Update.
Kurzgesagt hat mich eseutil /p in der Kommandozeile weiter gebracht.
Hier der Link zum ganzen Artikel:
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exc ...
Ich hoffe ich konnte dir helfen.
PS: Denkst du bitte an ein Server Back-Up? Ich hab hier schon leidvolle Erfahrungen gemacht. Kannst du mittels Acronis o.Ä. tun.
Grüße Lenny Linux
Hallo,
der Server wird jeden Tag mit Symantec BESR gesichert. Normalerweise läuft auch ein NTBACKUP mit, aber wegen einer Umstellung ist die letzte NTBACKUP-Sicherung schon älter.
So der chkdsk lief durch, und NTFS scheint wieder gerade zu sein, was man von der pub.stm nicht behaupten kann.
Als nächstes spiele ich das Backup auf meinem Testsystem ein und docktore da an dem rum, denn gemountet ist die DB und Empfang und versand von Mails geht nach wie vor.
Ich denke die Reparatur der DB werde ich aufs WE verschiebn, denn NTFS ist wieder da, also sollte nicht mehr kaput gehen als schon ist, wenn ich die DB in Ruhe lasse.
Ich hatte glesen, das bei Postfächern die Möglichkeit besteht, die Postfächer in PST zu sichern und dann die datenbank zu löschen/neu anlegen, dann eine Mail ann alle, damit die Postfächer wieder da sind und dann die PST zurückspielen.
Langwierige angelegenheit aber machbar.
Die Preisfrage wie mache ich das bei Öffentlichen Ordnern? Wenn ich die DB leer neu erstelle sind die ja alle inclusive Mailadressen verschwundibus.
Gruß
Chonta
der Server wird jeden Tag mit Symantec BESR gesichert. Normalerweise läuft auch ein NTBACKUP mit, aber wegen einer Umstellung ist die letzte NTBACKUP-Sicherung schon älter.
So der chkdsk lief durch, und NTFS scheint wieder gerade zu sein, was man von der pub.stm nicht behaupten kann.
Als nächstes spiele ich das Backup auf meinem Testsystem ein und docktore da an dem rum, denn gemountet ist die DB und Empfang und versand von Mails geht nach wie vor.
Ich denke die Reparatur der DB werde ich aufs WE verschiebn, denn NTFS ist wieder da, also sollte nicht mehr kaput gehen als schon ist, wenn ich die DB in Ruhe lasse.
Ich hatte glesen, das bei Postfächern die Möglichkeit besteht, die Postfächer in PST zu sichern und dann die datenbank zu löschen/neu anlegen, dann eine Mail ann alle, damit die Postfächer wieder da sind und dann die PST zurückspielen.
Langwierige angelegenheit aber machbar.
Die Preisfrage wie mache ich das bei Öffentlichen Ordnern? Wenn ich die DB leer neu erstelle sind die ja alle inclusive Mailadressen verschwundibus.
Gruß
Chonta
Guten Abend 
Ein kleiner Zwischenstatus.
Die Datenbankbeschädigung ist zu 80% einer defekten Platte mit vermehrt auftretenden Sectorrepairs zuzuschreiben die das Dateisystem in Mitleidenschaft gezogen haben.
Die Datenbank läst sich hochfahren, aber mit NTBACKUP nicht mehr sichern, die Imagesiherung BESR sichert die Platte und DB und eine Rücksicherung läuft dann auch ohne sichtbare Probleme und ohne NTBACKUP wären die Probleme auch nicht sichtbar geworden.
Also sicher kann man sich nur mir einer Onlinesicherung der Exchangedatenbanken sein!
Ein isinteg im Testmodus fand keine Fehler sondern nur Warnings bei Test Folder result und Test reference count verification.
Als erstes wird die HDD getauscht werden.
Danach wird dafür gesorgt, das der Exchange keine Mails mehr empfangen kann.
Mit einer Workstation wird dann über Outlook alles lesbare der DB (öffentliche Ordner) in eine PST gesichert.
Über PDFAdmin sind Einstellungen und Zugriffsrechte auf die Ordner exportiert.
Sollten alle Stricke reßen (esutil /p bzw vorher danach isinteg mit fix) wird eine leere DB angelegt, die PST zurückgesichert und dann mit PDFAdmin die Rechte zurück importiert.
So der Plan.
Wenn jemand Verbesserungsvorschläge/Erfahrungen hat immer her damit, wir wollen alle dazu lernen (ohne viel Schaden zu nehmen 
)
Gruß
Chonta
Nachtrag:
eseutil.exe /k d:\ExchangeDB\pub1.edb
Der Befehl prüft die edb und stm Datenbank.
Wie zu erwarten war die STM beschädigt.
Nachfolgend wurde
isinteg.exe -s home -fix -test alltests -verbose ausgeführt (vorher hatte ich auf einem anderen Rechner den Befehl ohne -fix durchgeführt, es gab nur Warnings keine Errors)
Alle Warnings wurden zu fixes
eseutil.exe /p d:\ExchangeDB\pub1.edb
-Sollte man alle benötigten Transaktionsprotokolle besitzen, dann sollte mannicht /p verwenden sondern die Datenbank mithilfe der Transaktionsprotokolle reparieren. Mit /p hat man Datenverlust zu befürchten, allerdings waren die Daten eh schon korrupt.
isinteg.exe -s home -fix -test alltests -verbose
Danmit wird die innere Logik der Datenbank sichergestellt.
eseutil.exe /k d:\ExchangeDB\pub1.edb
Konsistenz wiederhergestellt.
Datenbank repariert und NTBACKUP ist auch wiedr in der Lage zu sichern.
Ein kleiner Zwischenstatus.
Die Datenbankbeschädigung ist zu 80% einer defekten Platte mit vermehrt auftretenden Sectorrepairs zuzuschreiben die das Dateisystem in Mitleidenschaft gezogen haben.
Die Datenbank läst sich hochfahren, aber mit NTBACKUP nicht mehr sichern, die Imagesiherung BESR sichert die Platte und DB und eine Rücksicherung läuft dann auch ohne sichtbare Probleme und ohne NTBACKUP wären die Probleme auch nicht sichtbar geworden.
Also sicher kann man sich nur mir einer Onlinesicherung der Exchangedatenbanken sein!
Ein isinteg im Testmodus fand keine Fehler sondern nur Warnings bei Test Folder result und Test reference count verification.
Als erstes wird die HDD getauscht werden.
Danach wird dafür gesorgt, das der Exchange keine Mails mehr empfangen kann.
Mit einer Workstation wird dann über Outlook alles lesbare der DB (öffentliche Ordner) in eine PST gesichert.
Über PDFAdmin sind Einstellungen und Zugriffsrechte auf die Ordner exportiert.
Sollten alle Stricke reßen (esutil /p bzw vorher danach isinteg mit fix) wird eine leere DB angelegt, die PST zurückgesichert und dann mit PDFAdmin die Rechte zurück importiert.
So der Plan.
Wenn jemand Verbesserungsvorschläge/Erfahrungen hat immer her damit, wir wollen alle dazu lernen
(ohne viel Schaden zu nehmen )Gruß
Chonta
Nachtrag:
eseutil.exe /k d:\ExchangeDB\pub1.edb
Der Befehl prüft die edb und stm Datenbank.
Wie zu erwarten war die STM beschädigt.
Nachfolgend wurde
isinteg.exe -s home -fix -test alltests -verbose ausgeführt (vorher hatte ich auf einem anderen Rechner den Befehl ohne -fix durchgeführt, es gab nur Warnings keine Errors)
Alle Warnings wurden zu fixes
eseutil.exe /p d:\ExchangeDB\pub1.edb
-Sollte man alle benötigten Transaktionsprotokolle besitzen, dann sollte mannicht /p verwenden sondern die Datenbank mithilfe der Transaktionsprotokolle reparieren. Mit /p hat man Datenverlust zu befürchten, allerdings waren die Daten eh schon korrupt.
isinteg.exe -s home -fix -test alltests -verbose
Danmit wird die innere Logik der Datenbank sichergestellt.
eseutil.exe /k d:\ExchangeDB\pub1.edb
Konsistenz wiederhergestellt.
Datenbank repariert und NTBACKUP ist auch wiedr in der Lage zu sichern.
