Qnap 439 Pro 2 rebuild startet nicht

Hallo liebes Qnap-Team!

Habe folgendes Problem:
System: Qnap 439 pro 2
4x WD 1TB HDD im Raid 5
Firmware 3.3.0

Vor ca. 3 Wochen ist eine Platte (Slot 2) ausgefallen -> ausgebaut -> eingeschickt.
Der Austausch dauerte ca. 3 Wochen, während dieser Zeit arbeite das System für ca, 2 Wochen im degraded Modus "normal", d.h. lesen und schreiben funktionierte, nach ca- 2 Wochen erhielt ich eine EMail-Benachrichtigung vom System, dass ein eingerichtetes Backup von einem zweiten 439 Pro 2 nicht mehr auf dieses Backup-System schreiben kann. War nicht weiter tragisch weil der "Hauptserver" ja fehlerfrei war.
Heute habe ich die Austauschplatte bekommen, habe sie eingebaut und wartete auf das Rebuild, aber dieses startete nicht.
Habe daraufhin Firmware 3.4.0 installiert und das System rebootet. Alle 4 Platten werden als fehlerfrei angezeigt, rebuild startet aber immer noch nicht, Daten sind lesbar, aber schreiben nicht möglich.
Im Eventlog steht Rebuild skipped.
Habe jetzt einen HDD-Test gestartet und warte noch auf Ergebnis.

Gibt es zu diesem Problem weiterführende Infos?

LG
Bodo

Hallo!

Mir platzt vor lauter Stolz fast die Brust (tschulliung...)..., obwohl ich die Lösung nicht selber gefunden habe (an dieser Stelle ein dickes Lob und herzliches Dankeschön an Sasa, der mich mit seinen Linux-Kenntnissen auf den richtigen Weg gebracht hat!!!):

Hier die Anleitung die in MEINEM Falle zum Erfolg (= Starten des Rebuilds) geführt hat:

SSh-Session zur QNAP öffnen (z.B. mit Putty)
Anmelden mit einem administrativen Benutzer (der gleiche, mit dem ihr euch als Admin an der Webkonsole anmeldet -> erst Benutzer eintippen.., z.B. "admin", dann ENTER drücken, dann das Passwort angeben)
Dann hinter dem [~] # folgendes eingeben:

mdadm -w /dev/md0 (Erklärung: schaltet raid in den read/write-modus, sonst geht der nächste schritt nicht)

Dabei passiert weiter nichts, keine Systemmeldung oder sonstiges, es erscheint wieder [~] # und hier den nächsten Befehl eingeben:

mdadm -D /dev/md0 (Erklärung: dient zur Bestimmung welche Platte ausgefallen ist)

Als "Antwort" erscheint etwas wie:

/dev/md0:
Version : 00.90.03
Creation Time : Thu Jul 1 20:28:30 2010
Raid Level : raid5
Array Size : 2925580800 (2790.05 GiB 2995.79 GB)
Used Dev Size : 975193600 (930.02 GiB 998.60 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Tue Mar 15 20:00:15 2011
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : d9243f7e:0b607f2e:92943946:34b3748b
Events : 0.1816488

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 0 0 1 removed
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3

In dem letzten "Block"

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 0 0 1 removed
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3

lässt sich nun die Platte bestimmen, die nicht rebuildet werden kann (hinter "removed"), in diesem Fall ist es /dev/sdb3 (als logische Folge, wenn man sich die Reihung hinter den Platten mit dem RaidDevice State "activ sync" anschaut, fehlt hinter "removed" sdb3)

jetzt den nächsten Befehl eingeben:

mdadm --add /dev/md0 /dev/sdb3 (Erklärung: fügt die "fehlende" Platte als Spare hinzu, ACHTUNG zwischen /dev/md0 und /dev/sdb3 ist ein Leerzeichen und vor dem "add" sind zwei "--"!!! SDB3 war in MEINEM Fall die "fehlende" Platte, bitte entsprechend ausbessern, wenn es bei euch eine andere sein sollte)

Als Antwort auf diesen Befehl erscheint:

mdadm: re-added /dev/sdb3 (bedeutet, dass die sdb3 erfolgreich als SPARE-Platte hinzugefügt wurde)

nun der letzte Befehl um zu kontrollieren ob der Rebuild gestartet ist:

mdadm -D /dev/md0

Als Antwort sollte nun erscheinen:

/dev/md0:
Version : 00.90.03
Creation Time : Thu Jul 1 20:28:30 2010
Raid Level : raid5
Array Size : 2925580800 (2790.05 GiB 2995.79 GB)
Used Dev Size : 975193600 (930.02 GiB 998.60 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Tue Mar 15 20:04:06 2011
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1

Layout : left-symmetric
Chunk Size : 64K

Rebuild Status : 0% complete

UUID : d9243f7e:0b607f2e:92943946:34b3748b
Events : 0.1816676

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
4 8 19 1 spare rebuilding /dev/sdb3
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3

In der drittletzten Zeile steht nun spare rebuilding /dev/sdb3 und weiter oben Rebuild Status : 0% complete -> der Rebuild hat also begonnen, und kann durch erneute Eingabe von mdadm -D /dev/md0 kontrolliert werden!

Ich hoffe diese Anleitung hilft auch anderen Usern, die mit diesem Problem zu kämpfen haben!!!
Btw: von QNap habe ich, auch nach 3 Wochen, immer noch keine Reaktion bekommen...., ist mir bei Synology bisher noch nicht passiert, von deren Support habe ich sofort (am gleichen Tag) eine Hilfestellung bekommen!
Schade, dabei mag ich die QNap-System ansonsten recht gerne!

LG
BB