10
RAID1- Datenverlust beim Schreiben (EventID-51) - Festplatten und RAID - i.O.
HP Proliant Server
- 2 GB RAM
- 2x500GB SATA-HDDs
- (RAID1 über embedded Controller)
- Small-Business Server 2003
- Läuft seit 2008 ohne größere Probleme
Datenverlust beim Schreiben der Datei X - EventID 51
Hallo alle zusammen,
HP Proliant ML310 (G4) - Server
- 2 GB RAM
- 2x500GB SATA-HDDs
- (RAID1 über embedded Controller)
- Small-Business Server 2003
- Läuft seit 2008 ohne größere Probleme
Seit ca. einer Woche schreibt der Server nun auf die Serverkonsole, dass er gewisse Speichevorgänge nicht durchführen kann (von GDATA-Administrator Updates). Auch der eingebaute IIS schreibt, dass er Datenverlust beim Schreiben einiger Dateien hätte, man sollte die Hardware oder Netzwerkberbindung prüfen.
Der Eventlog dokumentiert die Fehler brav als Anwendungsfehler von GData und IIS in "Anwendung".
Unter "System" im Protokoll befinden sich unzählige Ereignisse mit der ID 51 Source Disk.
Die Beschreibung der Meldung ist: "Fehler bei der Auslagerung einer Datei".
Acronis True Image 9.1 kann seinen Sicherungstask nicht mehr durchführen: Lesefehler in der Quellfestplatte an Sektoren XXX.XX.XXX
Durchgeführte Troubleshooting Maßnahmen bisher.
Mit HP-Tools das Array und die Platten geprüft: SMART und Array-Check mit HP-Diagnostics sind einwandfrei.
- Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
- Fehlermeldungen tauchen nicht mehr auf
--> Ist jedoch keine Lösung - da Redundanz im Plattenbereich gewünscht.
- Erneutes Build des RAID1 - OK
- Boot und erneutes Anpassen des MBR - OK
- Event-ID 51 und oben beschriebene Fehlermeldungen tauchen erneut auf.
- Windows Update durchgeführt - Keine Änderung: Die Meldungen tauchen erneut auf.
- Gerade führen wir die aktuellsten Firmware-Updates von HP durch. (noch keine Rückmeldung)
Nach exzessiver Recherche:
- Viele schreiben dass das Problem auf fehlerhaften RAM zurückzuführen ist: HP-Diagnostics Tool schreibt dass RAM in Ordnung ist
- Andere weisen auf defekten IDE/SATA Port hin: IDE Kabel abgezogen, reboot - gleiches Problem
- Embedded SATA Controller ist ebenfalls in Ordnung
- Auslagerungsdatei mit festen Werten auf C: wurde umgestellt auf "Von System verwaltet"
An dieser Stelle gehen uns einfach die Ideen aus. Die Hardware ist in Ordnung und das System bootet - ist aber extrem langsam und viele Funktionen (wie z.B. Virenschutz, Companyweb(IIS) und Exchange funktionieren einfach nicht. SMB/CIFS Shares und Druckserver funktionieren, AD/DNS/DHCP funktionieren ebenfalls. Jedoch gibt der Server alle X Minuten ein aktustisches Signal via. PC-Speaker das eine Datei nicht geschrieben werden kann - oder dass ein Schreibprozess abgebrochen wurde.
- Hat jemand eine ähnliche Problematik schon einmal erlebt und oder behoben?
- Was könnten die nächsten Schritte im Troubleshooting sein - da es wohl ein Softwareproblem ist und nicht Hardware?
Zusatzinformationen:
- Es sind keine weiteren Festplatten an oder im Server verbaut oder angeschlossen (nur das RAID1 mit 500GB)
- Datensicherung des Servers und der Clients läuft über Acronis auf ein QNAP NAS mit 1TB Datenvolumen
- Ein 10/100er Switch und Breitband-Router (Speedport) mit 16.000er DSL von T-Com ist vorhanden
- Clients alle XP-SP3
Beste Grüße
anaxagoras83
- 2 GB RAM
- 2x500GB SATA-HDDs
- (RAID1 über embedded Controller)
- Small-Business Server 2003
- Läuft seit 2008 ohne größere Probleme
Datenverlust beim Schreiben der Datei X - EventID 51
Hallo alle zusammen,
HP Proliant ML310 (G4) - Server
- 2 GB RAM
- 2x500GB SATA-HDDs
- (RAID1 über embedded Controller)
- Small-Business Server 2003
- Läuft seit 2008 ohne größere Probleme
Seit ca. einer Woche schreibt der Server nun auf die Serverkonsole, dass er gewisse Speichevorgänge nicht durchführen kann (von GDATA-Administrator Updates). Auch der eingebaute IIS schreibt, dass er Datenverlust beim Schreiben einiger Dateien hätte, man sollte die Hardware oder Netzwerkberbindung prüfen.
Der Eventlog dokumentiert die Fehler brav als Anwendungsfehler von GData und IIS in "Anwendung".
Unter "System" im Protokoll befinden sich unzählige Ereignisse mit der ID 51 Source Disk.
Die Beschreibung der Meldung ist: "Fehler bei der Auslagerung einer Datei".
Acronis True Image 9.1 kann seinen Sicherungstask nicht mehr durchführen: Lesefehler in der Quellfestplatte an Sektoren XXX.XX.XXX
Durchgeführte Troubleshooting Maßnahmen bisher.
Mit HP-Tools das Array und die Platten geprüft: SMART und Array-Check mit HP-Diagnostics sind einwandfrei.
- Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
- Fehlermeldungen tauchen nicht mehr auf
--> Ist jedoch keine Lösung - da Redundanz im Plattenbereich gewünscht.
- Erneutes Build des RAID1 - OK
- Boot und erneutes Anpassen des MBR - OK
- Event-ID 51 und oben beschriebene Fehlermeldungen tauchen erneut auf.
- Windows Update durchgeführt - Keine Änderung: Die Meldungen tauchen erneut auf.
- Gerade führen wir die aktuellsten Firmware-Updates von HP durch. (noch keine Rückmeldung)
Nach exzessiver Recherche:
- Viele schreiben dass das Problem auf fehlerhaften RAM zurückzuführen ist: HP-Diagnostics Tool schreibt dass RAM in Ordnung ist
- Andere weisen auf defekten IDE/SATA Port hin: IDE Kabel abgezogen, reboot - gleiches Problem
- Embedded SATA Controller ist ebenfalls in Ordnung
- Auslagerungsdatei mit festen Werten auf C: wurde umgestellt auf "Von System verwaltet"
An dieser Stelle gehen uns einfach die Ideen aus. Die Hardware ist in Ordnung und das System bootet - ist aber extrem langsam und viele Funktionen (wie z.B. Virenschutz, Companyweb(IIS) und Exchange funktionieren einfach nicht. SMB/CIFS Shares und Druckserver funktionieren, AD/DNS/DHCP funktionieren ebenfalls. Jedoch gibt der Server alle X Minuten ein aktustisches Signal via. PC-Speaker das eine Datei nicht geschrieben werden kann - oder dass ein Schreibprozess abgebrochen wurde.
- Hat jemand eine ähnliche Problematik schon einmal erlebt und oder behoben?
- Was könnten die nächsten Schritte im Troubleshooting sein - da es wohl ein Softwareproblem ist und nicht Hardware?
Zusatzinformationen:
- Es sind keine weiteren Festplatten an oder im Server verbaut oder angeschlossen (nur das RAID1 mit 500GB)
- Datensicherung des Servers und der Clients läuft über Acronis auf ein QNAP NAS mit 1TB Datenvolumen
- Ein 10/100er Switch und Breitband-Router (Speedport) mit 16.000er DSL von T-Com ist vorhanden
- Clients alle XP-SP3
Beste Grüße
anaxagoras83
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: 173548
Url: https://administrator.de/forum/raid1-datenverlust-beim-schreiben-eventid-51-festplatten-und-raid-i-o-173548.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
10 Kommentare
Neuester Kommentar
Hi,
ist gedruckt und wird heute genauer unter die Lupe genommen.
Dankeschön - Beste Grüße
Anxagoras83
ist gedruckt und wird heute genauer unter die Lupe genommen.
Dankeschön - Beste Grüße
Anxagoras83
Hi !
Also wenn es die ganze Zeit, wie Du schreibst, bis vor ca. einer Woche funktioniert hat, dann muss eine Veränderung eingetreten sein. Um mir ein Bild machen zu können, bräuchte (zumindest) ich noch mehr Informationen. Wie hast Du z.B. die Platten getestet? Hast Du den RAM nur mit dem Tool von HP getestet oder auch mal (z.B. über Nacht) memtest darauf angesetzt? Auf die meisten Diagnosetools für RAID-Controller kann man sich übrigens nicht wirklich verlassen.
Also wenn ich bisher solche Meldungen an einem Server hatte, handelte es sich fast immer um einen Hardwaredefekt. Und gerade weil Du schreibst, mit nur einer Platte kommen keine Meldungen mehr, würde ich auf ein Problem mit dem Raid-Controller, dem Speicher oder einer Platte tippen. Hat der RAID Controller einen eigenen (Schreib-) Cache und kannst Du den mal disablen?
mrtux
Also wenn es die ganze Zeit, wie Du schreibst, bis vor ca. einer Woche funktioniert hat, dann muss eine Veränderung eingetreten sein. Um mir ein Bild machen zu können, bräuchte (zumindest) ich noch mehr Informationen. Wie hast Du z.B. die Platten getestet? Hast Du den RAM nur mit dem Tool von HP getestet oder auch mal (z.B. über Nacht) memtest darauf angesetzt? Auf die meisten Diagnosetools für RAID-Controller kann man sich übrigens nicht wirklich verlassen.
Also wenn ich bisher solche Meldungen an einem Server hatte, handelte es sich fast immer um einen Hardwaredefekt. Und gerade weil Du schreibst, mit nur einer Platte kommen keine Meldungen mehr, würde ich auf ein Problem mit dem Raid-Controller, dem Speicher oder einer Platte tippen. Hat der RAID Controller einen eigenen (Schreib-) Cache und kannst Du den mal disablen?
mrtux
moin,
Im Anschluß an die Fragen und die vielleichttrotz aus Erfahrung voreilige Schlussfolgerung von MrTux, der ich mich eigentlich anschliesse...
3 Jahre alte Platten... raus damit, sparst dir zu 99.9% einiges an bezahlter Zeit und unbezahltem Ärger.
und besser schlafen ist unbezahlbar
Gruß
Im Anschluß an die Fragen und die vielleicht
Durchgeführte Troubleshooting Maßnahmen bisher.
Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
- Meinst du
- zweimaliges booten mit je einer Festplatte mit dem identischen Ergebnis?
anpassung der MBR und Startparameter - OK
- sagt mir, du hast nur ein Weiches Raid und wenn das fliegen geht, ist dein beschriebenes Verhalten nachvollziehbar.
3 Jahre alte Platten... raus damit, sparst dir zu 99.9% einiges an bezahlter Zeit und unbezahltem Ärger.
und besser schlafen ist unbezahlbar
Gruß
Hallo anaxagoras83
Aha
mit neuer Platte ? - sonst hast du den Fehler schon gefunden
Nach 3 Jahren sollten Serverplatten eh getauscht werden - also lieber beide tauschen, dann erst weitersuchen
chkdsk
USV
gruss p
Acronis True Image 9.1 kann seinen Sicherungstask nicht mehr durchführen: Lesefehler in der Quellfestplatte an Sektoren
Aha
--> Ist jedoch keine Lösung - da Redundanz im Plattenbereich gewünscht.
- Erneutes Build des RAID1 - OK
- Erneutes Build des RAID1 - OK
mit neuer Platte ? - sonst hast du den Fehler schon gefunden
Nach 3 Jahren sollten Serverplatten eh getauscht werden - also lieber beide tauschen, dann erst weitersuchen
chkdsk
USV
gruss p
@mrtux,
- Die Festplatten wurde zum einen mit dem HP-Diagnostic Tool überprüft, weiterhin haben wir jedoch eine SMART-Überprüfung der einzelnen Festplatten inkl. Self-Test über Parted-Magic(Live-CD) ausgeführt. Er zeigt natürlich eine entsprechende Laufzeitdauer der Festplatten an, jedoch wurden keinerlei Fehler festgestellt.
- Der RAM-Speicher wurde über den Advanced Self-Test des Systems und über das Diagnosesystem von HP duchgeführt (das Diagnosesystem baut laut Aussagen von HP auf Memtest auf)
- Die beiden Festplatten sind in Ordnung. Sie wurden wie oben beschrieben mit SMART und Co. getestet.
- Die Caching Funktion war die ganze Zeit deaktiviert, wir haben diesen jetzt Testweise mal aktiviert.
- RAID/SATA Controller funktioniert wie gesagt durch Deaktivierung des RAID-Systems aber mit dem gleichen physikalischen Controller und der gleichen Steckverbindung einwandfrei.
Also wenn es die ganze Zeit, wie Du schreibst, bis vor ca. einer Woche funktioniert hat, dann muss eine Veränderung
eingetreten sein. Um mir ein Bild machen zu können, bräuchte (zumindest) ich noch mehr Informationen. Wie hast Du z.B.
die Platten getestet? Hast Du den RAM nur mit dem Tool von HP getestet oder auch mal (z.B. über Nacht) memtest darauf
angesetzt? Auf die meisten Diagnosetools für RAID-Controller kann man sich übrigens nicht wirklich verlassen.
eingetreten sein. Um mir ein Bild machen zu können, bräuchte (zumindest) ich noch mehr Informationen. Wie hast Du z.B.
die Platten getestet? Hast Du den RAM nur mit dem Tool von HP getestet oder auch mal (z.B. über Nacht) memtest darauf
angesetzt? Auf die meisten Diagnosetools für RAID-Controller kann man sich übrigens nicht wirklich verlassen.
- Die Festplatten wurde zum einen mit dem HP-Diagnostic Tool überprüft, weiterhin haben wir jedoch eine SMART-Überprüfung der einzelnen Festplatten inkl. Self-Test über Parted-Magic(Live-CD) ausgeführt. Er zeigt natürlich eine entsprechende Laufzeitdauer der Festplatten an, jedoch wurden keinerlei Fehler festgestellt.
- Der RAM-Speicher wurde über den Advanced Self-Test des Systems und über das Diagnosesystem von HP duchgeführt (das Diagnosesystem baut laut Aussagen von HP auf Memtest auf)
Also wenn ich bisher solche Meldungen an einem Server hatte, handelte es sich fast immer um einen Hardwaredefekt. Und gerade weil
Du schreibst, mit nur einer Platte kommen keine Meldungen mehr, würde ich auf ein Problem mit dem Raid-Controller, dem
Speicher oder einer Platte tippen. Hat der RAID Controller einen eigenen (Schreib-) Cache und kannst Du den mal disablen?
Du schreibst, mit nur einer Platte kommen keine Meldungen mehr, würde ich auf ein Problem mit dem Raid-Controller, dem
Speicher oder einer Platte tippen. Hat der RAID Controller einen eigenen (Schreib-) Cache und kannst Du den mal disablen?
- Die beiden Festplatten sind in Ordnung. Sie wurden wie oben beschrieben mit SMART und Co. getestet.
- Die Caching Funktion war die ganze Zeit deaktiviert, wir haben diesen jetzt Testweise mal aktiviert.
- RAID/SATA Controller funktioniert wie gesagt durch Deaktivierung des RAID-Systems aber mit dem gleichen physikalischen Controller und der gleichen Steckverbindung einwandfrei.
Im Anschluß an die Fragen und die vielleicht trotz aus Erfahrung voreilige Schlussfolgerung von
MrTux, der ich mich eigentlich anschliesse...
> Durchgeführte Troubleshooting Maßnahmen bisher.
> Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
MrTux, der ich mich eigentlich anschliesse...
> Durchgeführte Troubleshooting Maßnahmen bisher.
> Booten des Systems mit nur einer Festplatte und anpassung der MBR und Startparameter - OK
- Meinst du
- zweimaliges booten mit je einer Festplatte mit dem identischen Ergebnis?
Ja das ist richtig
> anpassung der MBR und Startparameter - OK
- sagt mir, du hast nur ein Weiches Raid und wenn das fliegen geht, ist dein beschriebenes Verhalten nachvollziehbar.
Es ist wohl ein "Fake-Raid-Controller" aber eines der besseren Sorte (wenn es das gibt).
3 Jahre alte Platten... raus damit, sparst dir zu 99.9% einiges an bezahlter Zeit und unbezahltem Ärger.
und besser schlafen ist unbezahlbar
und besser schlafen ist unbezahlbar
Das wollten wir auch direkt tun - aber die Platten sind wirklich erstaunlich zäh und halten sich gut. Keine Cycle-Warnung, keine Temp. oder Sektorenprobleme, gar nix. alles in Ordnung. Es ist zwar eine option, aber lößt das Problem nicht.
> Acronis True Image 9.1 kann seinen Sicherungstask nicht mehr durchführen: Lesefehler in der Quellfestplatte an Sektoren
Aha
Aha
Das dachte ich mir auch - jetzt aber meine Frage: Es ist ein Mirror - von welchen Sektoren spricht er? das Array hat ja keine physikalischen Sektoren, oder sehe ich das falsch?
> --> Ist jedoch keine Lösung - da Redundanz im Plattenbereich gewünscht.
>
> - Erneutes Build des RAID1 - OK
mit neuer Platte ? - sonst hast du den Fehler schon gefunden
>
> - Erneutes Build des RAID1 - OK
mit neuer Platte ? - sonst hast du den Fehler schon gefunden
Die Wiedeherstellung wurde auf die gleiche Platte gemacht, da diese ja nach Tests i.O. scheint.
Wie schon erwähnt - vielleicht bin ich da zu stur - aber bisher konnten wir den SMART- Tests vertrauen. Wenn SMART sagte es sind Fehler gefunden worden, hatten wir mit einer sehr hohen Wahrscheinlichkeit diese Fehler auch in den Testtools der Plattenhersteller.
Ich sträube mich ja nicht gegen die Idee neue Platten einzubauen, aber es wäre doch ebenfalls auch Schade, wenn das Problem einfach nicht an der Hardware liegen würde. Mir wäre ein Hardwaredefekt wirklich lieber - aber momentan spricht (jedenfalls nach meiner Einschätzung) alles _gegen_ einen Plattendefekt.
Nach 3 Jahren sollten Serverplatten eh getauscht werden - also lieber beide tauschen, dann erst weitersuchen
chkdsk
USV
chkdsk
USV
Checkdisk ist allerding eine großartige Idee!
Da habe ich noch nicht dran gedacht. Werde ich gleich einmal durchführen.
Was genau meintest du mit USV? Eine USV ist an den Server angeschlossen.
Beste Grüße
Ich sträube mich ja nicht gegen die Idee neue Platten einzubauen, aber es wäre doch ebenfalls auch Schade, wenn das
Problem einfach nicht an der Hardware liegen würde. Mir wäre ein Hardwaredefekt wirklich lieber - aber momentan spricht
(jedenfalls nach meiner Einschätzung) alles _gegen_ einen Plattendefekt.
> Nach 3 Jahren sollten Serverplatten eh getauscht werden - also lieber beide tauschen, dann erst weitersuchen
>
Problem einfach nicht an der Hardware liegen würde. Mir wäre ein Hardwaredefekt wirklich lieber - aber momentan spricht
(jedenfalls nach meiner Einschätzung) alles _gegen_ einen Plattendefekt.
> Nach 3 Jahren sollten Serverplatten eh getauscht werden - also lieber beide tauschen, dann erst weitersuchen
>
So .. Checkdisk ausgeführt. Leider blieb er mitten im arbeiten stehen (noch bevor er irgendetwas gemacht hat) aber in der Vorbereitung nach absenden des Befehls, bekamen wir ca. 2 Stunden lang Plattenarbeitsgeräusche auf die Ohren.
Nun haben wir zwei neue 500GB Platten eingebaut und ein Klon auf eine der Platten gespielt. Nach dem Klon wird - gerade - im RAID-BIOS ein neues RAID erstellt (mit der Build Methode).
So - um den Kommunikationsfluss nicht zu stoppen:
1) Neue Festplatten eingebaut
2) Klon auf die erste Festplatte mit Stand vor den "Experimenten"
3) Zugriff auf das RAID-BIOS - OK
4) Rebuild des Arrays mit der geklonten Platte als Source
5) Boot von der Festplatte - Fehler (keine Registry gefunden in /system32/config)
6) Booten von Installationscd Zugriff auf das Verzeichnis (Fehler bei der Auflistung der Dateien)
7) Checkdisk angeworfen - nach ca. 12 Stunden fertig
8) Reboot und Test des Systems - OK
9) Heute liefern wir nach dem Durchführen der versäumten Updates,
den Server aus und schauen ob die Dienste wie Exchange auch wieder funktionieren.
Ich markiere des Beitrag als gelößt und danke allen Beteiligten für den Input.
Hoffe auch einmal helfen zu können.
Beste Grüße
anaxagoras83
1) Neue Festplatten eingebaut
2) Klon auf die erste Festplatte mit Stand vor den "Experimenten"
3) Zugriff auf das RAID-BIOS - OK
4) Rebuild des Arrays mit der geklonten Platte als Source
5) Boot von der Festplatte - Fehler (keine Registry gefunden in /system32/config)
6) Booten von Installationscd Zugriff auf das Verzeichnis (Fehler bei der Auflistung der Dateien)
7) Checkdisk angeworfen - nach ca. 12 Stunden fertig
8) Reboot und Test des Systems - OK
9) Heute liefern wir nach dem Durchführen der versäumten Updates,
den Server aus und schauen ob die Dienste wie Exchange auch wieder funktionieren.
Ich markiere des Beitrag als gelößt und danke allen Beteiligten für den Input.
Hoffe auch einmal helfen zu können.
Beste Grüße
anaxagoras83
