volume 1 was crashed - Raid 5 abgestürzt

[by_alu]

Hallo,

als wir gerade am Planen unserer neuen Backuplösung und des Ersatzplattenkaufs sind, kommt auf einmal die folgende Mail:

"Sehr geehrter Benutzer,
Das Volume 1 auf Sekretariat ist abgestürzt, der Server kann möglicherweise nicht hochgefahren werden.
Kontaktieren Sie für weitere Unterstützung bitte den Synology Online Support. http://www.synology.com.
Mit freundlichen Grüßen
Synology DiskStation"


weitere Infos:
DS509+ mit 5 x 1TB als RAID5
Platte 4 kürzlich wegen i/o-error getauscht (rund 3 Jahre 24/7)
Platte 2 meckert seit ein paar Tagen wegen i/o-error, daher die Plattenkaufabsichten

Nach dem Absturz des Raids funktionierte die Weboberfläche noch, ich habe noch schnell die allerwichtigsten Daten gesichert und dann übers Webinterface neu gestartet. System kam aber nicht mehr hoch. Habe dann weil keine Reaktion mehr war den Stecker gezogen. Bin dann zum Abendessen nach Hause, als ich wieder gekommen bin lief die DS wieder.

Danach ist in /var/log/messages folgendes zu lesen gewesen:

Attachment: Anhang anzeigen ds509-messages.txt

Wer kann mir sagen, was dem System genau (Platten Nr. ???) den Rest gegeben hat? Was ist in der Stunde in der ich zu Hause war restauriert worden?
Dass da schnellstens neue Platten reinmüssen ist mir klar!

Grüße
by_alu

 

[by_alu]

Habe gerade Supamans Nachricht gelesen und bin mir nicht sicher ob ich hier richtig war, bin es jetzt aber wahrscheinlich, weil ich gerne meine Daten über die Konsole retten und auf eine externe 500GB-USB-Platte packen würde, die DS lässt mich aber nicht.

Habe unter Win7 einen Ordner F:\bak angelegt und würde gerne dort hineinkopieren. Dann Platte an DS angeschlossen. Habe also cp -R /volume1/* /volumeUSB1 gemacht und dann kurz darauf den Prozess abgebrochen um mal im Webinterface zu schauen ob auch was kopiert wurde. Die Platte hing ja per USB an der DS, dort wurde aber auch nach "Aktualisieren" nichts angezeigt. Zurück an der Konsole waren aber Daten vorhanden. Nach Wechsel an Win 7 waren keine Daten im angegebenen Ordner, aber wieder an der DS waren Sie in der Konsole zu sehen, im Webinterface wurde jetzt nicht mal mehr die USB-Platte angezeigt. Das ist jetzt alles sehr bizarr.

 

[jahlives]

Mhm wenn du die Daten auf der Konsole sehen kannst und auf der Platte am PC ned, dann tippe ich drauf, dass die Platte nicht sauber gemountet war und du die Daten in Wirklichkeit auf die Systempartition der DS geschrieben hast.
Gib mal das Kommando

df

auf der Konsole der DS ein. Bin mir aufgrund deiner Beschreibung fast sicher, dass die Systempart voll ist. Darum hat der cp wohl auch abgebrochen, weil kein Platz mehr war

 

[by_alu]

Teilproblem gelöst

Puh, jetzt läuft das Backup über die Konsole. Mann ist das gemein! Hatte ja meinen Backup-Ordner unter Windows nach F:\bak gelegt.

Auf der Konsole hatte ich den Ordner unter /volumeUSB1 nicht sehen können und ihn deshalb über mkdir nochmal angelegt. offenbar ist /volumeUSB1 aber nicht der mountpunkt für die Platte, die liegt nämlich im Ordner /volumeUSB1/usbshare, ich habe also, wie du richtig vermutet hast, irgendwo auf die Systempartition geschrieben ...

Habe den Schrott von der Systempartition gelöscht und jetzt schnurrt das Backup vor sich hin ............. 315 GB to go

Hoffe das ist bis morgen früh fertig, dann wollen Leute damit bis zum nächsten Crash oder bis zum Eintreffen der neuen Platten arbeiten

Danke
by_alu

 

[Merthos]

Mount Points beachten! Da ist immer noch ein Ordner drunter bei den externen.

Edit: Hast es ja selber bemerkt.

 

[by_alu]

Wer möchte darf mir natürlich trotzdem noch erklären, welche meiner Platten gemäß des logs in meinem Anfangspost die Übeltäter sind oder was man sonst noch rauslesen kann ... damit bin ich etwas überfordert!

Danke schonmal an alle Barmherzigen!

Grüße
by_alu

 

[jahlives]

Ich bin mir aufrgund der Logs nicht unbedingt sicher, dass es eine Platte an sich ist, die das Problem macht. Könnte auch ein angeschlagenes Dateisystem sein. Gerade wenn du mal den Strom kappen musstet, kann es sein, dass die DS nicht wirklich hängengeblieben war, sondern nur versucht hat Fehler im Dateisystem zu reparieren und das kann sehr lange dauern.
mach erstmal das Backup aller Daten und prüfe auch dass das Backup korrekt ist, sprich du die Dateien nutzen kannst. Dann würde ich mal probieren das Dateisystem von volume1 nach Fehlern zu scannen. Wie genau man das macht können wir dann ja angehen, wenn dein Backup durch ist
Btw Hast du dir mal die SMART Werte der Platten im DSM angeschaut? Irgendwelche auffälige Werte?

 

[Merthos]

sdb3 hatte die Fehler. Steht im Log als Disk 1, aber keine Ahnung, ob damit auch der Einschub gemeint ist. Kann aber wie wie von jahlives schon gesagt, auch einfach so passieren. Aber wenn Du Platten testen willst, dann würde ich mit der anfangen.

 

[jahlives]

@Merthos
ich dachte wegen der Journal-Sache im Log eher ans Dateisystem. Ich habe eine DS109+ bei der auch immer wieder mal das volume rausfliegt. Mache ich in diesem Fall einen reboot gehts endlos lange. Mache ich vor dem reboot einen e2fsck dann schreibt es jeweils Journaldaten und ist in ein paar Sekunden durch. reboot ohne e2fsck führt bei mir dann zu echten Fehlern im Dateisystem. Wohl wegen dem quotacheck beim reboot. ein folgendes e2fsck findet dann immer wieder "inodes" die ausserhalb der Grenzen liegen würden und erst wenn diese Fehler gefixt sind läuft mein volume wieder sauber

Gruss

tobi

 

[by_alu]

Vielleicht steckt noch mehr dahinter ...

@Merthos/jahlives
Danke für die Infos, d.h. es kommen da auch noch andere Probleme in Betracht. Wir hatten in der Vergangenheit häufiger das Problem, dass angeblich Daten in Dokumenten, Datenbankdateien, Programmverzeichnissen ohne Fehlermeldung nicht geschrieben wurden. Dazu kamen recht undurchsichtige Rechteprobleme, die nach Abschalten des CIFS-Papierkorbs einfach wieder weg waren (vgl. hier).

Nun gut, wenn das Backup gelaufen ist, hoffe ich, dass mir jemand ein bisschen Licht auf dem dunklen Konsolenpfad zum Dateisystem spendet.

Grüße
by_alu

 

[Merthos]

"failed command: READ FPDMA QUEUED", "I/O error, dev sdb" oder "Emask 0x409 (media error)" klingt ehr nach einem Fehler im Controller, der Festplatte oder ein kurzer Wackler bzw. genereller Fehler am Kabel. Ersteres wollen wir mal nicht hoffen, weil dann wäre die komplette DS auszutauschen. Das zweite und dritte kann man durch Test der Platte überprüfen bzw. durch Tausch korrigieren.

Die Dateisystemfehler sind mMn dann ehr eine Folge.

 

[by_alu]

i/o-error beim Backupversuch!

Hallo Merthos,

Update: Backup ist wegen i/o-error in der Konsole abgebrochen!

Das heißt, du würdest jetzt die Platte, die zuletzt angemeckert wurde und vielleicht auch die eine, die ich neulich schon mal getauscht habe nehmen, irgendwo dranstecken oder einbauen und ein Diagnosetool drüberlaufen lassen, um zu sehen, ob die Platte wirklich was hat. Wenn nicht, dann alle Plattenkabel (???) überprüfen, dran rumwackeln usw. und dann nochmal das System mit den alten Platten unter Last testen ? Oder gleich andere Platte rein und hoffen, dass sich der Raid-Verbund wieder synchronisiert?

Grüße
by_alu

 

[Merthos]

Klingt nach einem Plan. Das Backup müsste mit den nachfolgenden Dateien weitergehen können, ist ggf. nur etwas umständlich, diese rauszukriegen.

Ob das Raid was retten kann, könntest Du probieren, indem Du die eine Platte ausnimmst (degraded Raid). Wenn dann der Zugriff auf die fehlerhafte Datei geht, ist alles OK, wenn nicht hast Du hoffentlich ein Backup. Spart (erst mal) die Zeit für das Rebuild.

Persönlich würde ich (Backup und Zeit vorausgesetzt) alles neu aufsetzen und dabei alle alten Platten vorher testen. Anschließend noch ein bissel Stresstest auf dem neuen Raid.
In dem Zuge eventuell auch das Raid komplett überdenken, eventuell sind ja Basisvolumen mit internem (Time-)Backup eine bessere Lösung.

 

[by_alu]

update

Hallo,

habe gestern Abend eine neue Platte für HDD Nr. 2 eingebaut, das System brauchte sehr lange um hochkommen, war für mich unter diesen Unmständen aber verständlich. Dann lief die Box piepsend hoch, im Webinterface hab ich den Piepton deaktiviert und Reparieren des "degraded raid" gewählt. Nach einiger Zeit war dann die Paritätsprüfung abgeschlossen, ein Schnelltest der Platten (für den ausführlichen ist keine Zeit, außerdem ist das letzte Backup nicht ganz aktuell) ergab keine Fehler.

Überraschung: Alle home-Verzeichnisse sind nicht ansprechbar. In der FileStation sieht man als admin sein home aber nicht das Verzeichnis homes. Unter Windows-Explorer wird kein home-Ordner mehr angezeigt. Zugriffe auf die Home-Ordner funktionieren nicht.

Die Konsole zeigt mir /homes in /volume1 noch an, es ist auch noch was drin! Unter 'Benutzer' ist auch der Verzeichnis-home-Dienst aktiviert, lässt sich aber nicht mehr deaktivieren. Es kommt eine Fehlermeldung, die mir sagt, das gehe jetzt nicht, ich soll mich am DSM nochmal neu anmelden.

Ach ja, unter /usr/syno/etc/smb.conf steht auch kein [homes] mehr drin. Ich will das jetzt über planloses Konsolengebastel aber nicht komplett töten, denn alle anderen Shares gehen.

Irgendjemand eine Idee?

Grüße
by_alu

 

[by_alu]

up-update

Hallo,

worst case ist scheinbar eingetreten, denn ein Teil der Dateien, die wir auf der DS liegen hatten ist korrupt, dieses Backup ist also Schrott. Hatte auf einer zweiten DS ebenfalls ein Backup über das Netzwerkbackup, auch hier haben sich die defekten Dateien breit gemacht. Ich hatte zum Glück noch eine kleine USB-Platte einstecken als die ersten Probleme anfingen, die hatte ich über Nacht drangehängt und von der Konsole aus ein Vollbackup gemacht. Hier sind einige der in den "aktuelleren" Schrottbackups enthaltenen Dateien noch OK

Jetzt kämpfe ich nach der Erstellung eines neuen Volumes und der Neueunrichtung noch mit den Datei- und Sambarechten aus dem Backup. Da google und probier ich aber erst mal, bevor ich Fragen stelle.

Das System braucht jetzt zumStarten wenigstens keine 15 Minuten mehr

by_alu