TVS-863 RAID 5 - status FAILED, Rescue nach falschen Festplatten ziehen

    Hallo liebe QNAP Gemeinde,


    bei meinem RAID5 Verbund mit 8 x 6GB Platten war die DISK3 ausgefallen. Das habe ich zum Anlass genommen, alle Platten zu tauschen und gleichzeitig die Speicherkapazität zu erhöhen. Daher habe ich als ersten die defekte DISK3 gegen eine 16TG Platte ersetzt. Danach war wieder alles gut :D

    Also mit den Platten 1, 2, 4, 5, 6, 7 weiter gemacht. Alles wunderbar. Nach jedem Plattentausch hat der Resync ca. 14 Stunden gedauert. Und dann war die Euphorie beim letzten Plattentausch, die mich hat unachtsam sein lassen :rolleyes:

    Über den Speichermanager hatte ich jeweils die zu tauschende Festplatte angewählt und ersetzt. Bei der letzte Platte habe ich jedoch statt der DISK8 die DISK7 gezogen. Als ich die neue Platte einsetzen wollte, ist mir das Missgeschick aufgefallen! DISK7 war gezogen und DISK8 war noch die alte Platte. Und jetzt wurde es richtig doof. Anstatt, dass ich die DISK7 wieder stecke und abwarte, was passiert, habe ich DISK8 gezogen =O


    Im dem Moment, als ich die Platte gezogen habe frage ich mich, was ich da mache, aber da war es natürlich schon zu spät. Also habe ich die alte DISK8 wieder zurück gesteckt und die DISK7 auch wieder gesteckt.

    Über die Konsole habe ich nun folgende Ausgaben:




    Seit fast 19 Stunden ist der der "md1_raid5" Prozess konstant zwischen 18 und 30%. Auf die Weboberfläche komme ich leider nicht mehr, da ich das NAS herunter fahren wollte. Es popt der Fenster auf, dass das NAS herunter gefahren.


    Code
    Mem: 13988228K used, 1377320K free, 249644K shrd, 6142792K buff, 546496K cached
CPU: 34.4% usr 10.2% sys  0.0% nic  0.0% idle 55.2% io  0.0% irq  0.0% sirq
Load average: 198.67 197.08 190.89 4/2190 24131
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 6615     2 admin    RW<      0  0.0   1 20.7 [md1_raid5]
 8550  7616 admin    S    1103m  7.3   0 20.7 container-station/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --bridge=lxcbr0 --tlsverify --tlscacert=/etc/docker/tls/ca.pem --tlscert=/etc/docker/tls/server.pem --tlskey=/et
 8198  8171 admin    S    1147m  7.6   3  0.5 container-station/containerd --config /var/run/system-docker/containerd/containerd.toml --log-level debug
 8171  7616 admin    S    1175m  7.8   3  0.5 container-station/dockerd -H unix:///var/run/system-docker.sock --bridge=docker0 --storage-driver=overlay2 --dns 10.0.5.1 --data-root=/var/lib/system-docker --exec-root=/var/run/system-docker
 7739     2 admin    SW       0  0.0   0  0.4 [notify thread]



    Jetzt habe ich schon sehr Vieles gelesen und hatte versucht, die DISK8 mit mdadm /dev/md1 -r /dev/sdf3 aus dem Verbund zu nehmen, um sie mit mdadm /dev/md1 -a /dev/sdf3 wieder einzubinden, aber nach dem absetzen des ersten Befehls passiert minutenlang nichts.

    Was mich auch wundert, dass die DISK7 als removed angezeigt wird. Auch ein ziehen und erneutes Stecken ändert an diesem Zustand nichts. Daher war mein Gedanke, erst mal wieder die DISK8 einzubinden und sich dann um DISK7 zu kümmern. Wobei ich beim Schreiben dieser Zeilen setzt unsicher bin, ob ich in SLOT7 wirklich die korrekt synchronisierte DISK 7 oder die leere DISK8 eingesetzt habe. Denn diesmal habe ich die neuen Platten nicht mit den Steckplätzen beschriftet :cursing:


    Tja und jetzt sitze ich hier und traue mich keinen Schritt weiter. Denn was dazu kommt, der Stand meines Backups ist eine Woche alt. Und ausgerechnet in dieser Zeit habe ich einen Berg Videodaten von meiner Tochter "zwischengespeichert" und diese, wie soll es in so einer Situation auch anders sein, noch nicht gesichert :rolleyes:


    Anbei ein Screenshot des letzten "erfolgreichen" Synchronisationsprozesses von DISK 7


    Viele Grüße und einen schönen Sonntag!

    Eric

    Hätte, hätte, Fahradkette: Jedes Resync ist überpropotinaler Stress für die Festplatten. Selbst wenn du nichts falsch machst, ist das Risiko eines weiteren Ausfalls ungleich höher. Ein aktualisiertes Backup vor Austausch der defekten Platte wäre angebracht gewesen.

    Raid 5 kann genau den Ausfall einer HD vertragen, in dem Moment wo du noch eine zweite HD gezogen hast, kannst du die Daten abschreiben.


    Schreibe QNAP per Ticket an, ob die hier helfen können.


    Bitmap im Raid Pool könnte in dem Fall von HD 7 helfen, denn wenn keine Änderungen erfolgten, ist die HD dank Bitmap in wenigen Sekunden wieder ins Raid integrierbar.

    Das war aber vermutlich nicht an, denn sonst hätte die HD 7 sich ggf. gerade eben so wieder online melden können, bevor die HD 8 gezogen wurde.

    @Crazyhorse

    Denn versuche ich mal mein Glück beim QNAP Support :)