TS-853A - Raid 5 - Raid Inaktiv nach Anomaler Festplatte

    Hallo Forum,


    ich hoffe einer der Linuxexperten hier kann mir weiter helfen.


    Ich habe ein TS-853A mit 8 Festplatten im Raid 5.
    Am Freitag schaltete sich das NAS in den schreibgeschützten Modus, da Platte 6 Anomal und Platte 8 Warnung anzeigte. Also zwei neue Festplatten gleichen Typs (WD Red WD40EFRX) besorgt. Im Hot-Swap die Platte 6 entfernt und neue Platte eingesetzt.. Jetzt zeigte Platte 8 an sie wäre auch entfernt. Also Platte 8 entfernt und wieder eingesteckt. Jetzt wird angezeigt, dass das Raid nicht mehr schreibgeschützt, sondern inaktiv ist. Ein Rebuild der Platte 6 startet nicht. Dafür wird jetzt sowohl Platte 8, als auch Platte 7 zusätzlich als Anomal angezeigt. Beim Raid auf wiederherstellen drücken führt zu einem "unbekannten Fehler". Sowohl mit neuer Platte, als auch mit alter Platte. Momentan ist die alte Platte wieder eingesetzt.


    Gucke ich mir das Raid an, wird Platte 6 nicht angezeigt, 1-5 als gut und 7-8 mit Fehler.
    Ich komme sowohl per Weboberfläche, als auch per SSH auf das NAS.
    Aus einem anderen Topic hier habe ich ein paar Codeschnipsel zur Statusabfrage, die ich hier gleich einfüge. Wenn ich das richtig interpretiere fehlen die Platten 6-8 im Raid. Wenn es also möglich wäre, das Raid wieder mit allen 8 Platten manuell zu mounten (da das Wiederherstellen über die Weboberfläche ja nicht funktioniert), so dass das Raid wieder im schreibgeschützten Modus wäre um die Platten einzeln auszutauschen, wäre mir sehr geholfen.


    Mein Linuxwissen ist sehr beschränkt, aber vielleicht kann mir einer der Profis hier ja ein paar Codeschnipsel vorbereiten, mit denen ich das Raid unmounten und wieder neu zusammen setzen kann. Oder Ihr habt vielleicht andere Ideen, wie ich das wieder zum laufen bringen kann.


    Vielen Dank im Voraus. Jetzt füge ich noch die Codeschnipsel und ein paar Screenshots ein.


    Viele Grüße, Sebastian





    Code
    [~] # cat /proc/mountsnone / tmpfs rw,relatime,size=256000k,mode=755 0 0devtmpfs /dev devtmpfs rw,relatime,size=1965956k,nr_inodes=491489,mode=755 0 0/proc /proc proc rw,relatime 0 0devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0sysfs /sys sysfs rw,relatime 0 0tmpfs /tmp tmpfs rw,relatime,size=65536k 0 0tmpfs /dev/shm tmpfs rw,relatime 0 0tmpfs /share tmpfs rw,relatime,size=16384k 0 0tmpfs /mnt/snapshot/export tmpfs rw,relatime,size=16384k 0 0/dev/md9 /mnt/HDA_ROOT ext4 rw,relatime,nodelalloc,data=ordered 0 0cgroup_root /sys/fs/cgroup tmpfs rw,relatime 0 0none /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0/dev/md13 /mnt/ext ext4 rw,relatime,nodelalloc,data=ordered 0 0/dev/ram2 /mnt/update ext2 rw,relatime,errors=continue 0 0tmpfs /samba tmpfs rw,relatime,size=65536k 0 0tmpfs /samba/.samba/lock/msg.lock tmpfs rw,relatime,size=16384k 0 0tmpfs /mnt/ext/opt/samba/private/msg.sock tmpfs rw,relatime,size=16384k 0 0tmpfs /mnt/rf/nd tmpfs rw,relatime,size=1024k 0 0


    Code
    [~] # cat /proc/partitionsmajor minor  #blocks  name   1        0     204800 ram0   1        1     458752 ram1   1        2     458752 ram2   1        3     204800 ram3   1        4     204800 ram4   1        5     204800 ram5   1        6     204800 ram6   1        7     204800 ram7   1        8     204800 ram8   1        9     204800 ram9   1       10     204800 ram10   1       11     204800 ram11   1       12     204800 ram12   1       13     204800 ram13   1       14     204800 ram14   1       15     204800 ram15   8        0 3907018584 sda   8        1     530125 sda1   8        2     530142 sda2   8        3 3897063763 sda3   8        4     530144 sda4   8        5    8353796 sda5   8       16 3907018584 sdb   8       17     530125 sdb1   8       18     530142 sdb2   8       19 3897063763 sdb3   8       20     530144 sdb4   8       21    8353796 sdb5   8       32 3907018584 sdc   8       33     530125 sdc1   8       34     530142 sdc2   8       35 3897063763 sdc3   8       36     530144 sdc4   8       37    8353796 sdc5   8       48 3907018584 sdd   8       49     530125 sdd1   8       50     530142 sdd2   8       51 3897063763 sdd3   8       52     530144 sdd4   8       53    8353796 sdd5   8       64 3907018584 sde   8       65     530125 sde1   8       66     530142 sde2   8       67 3897063763 sde3   8       68     530144 sde4   8       69    8353796 sde5   8       80 3907018584 sdf   8       81     530125 sdf1   8       82     530142 sdf2   8       83 3897063763 sdf3   8       84     530144 sdf4   8       85    8353796 sdf5   8       96 3907018584 sdg   8       97     530125 sdg1   8       98     530142 sdg2   8       99 3897063763 sdg3   8      100     530144 sdg4   8      101    8353796 sdg5   8      112 3907018584 sdh   8      113     530125 sdh1   8      114     530142 sdh2   8      115 3897063763 sdh3   8      116     530144 sdh4   8      117    8353796 sdh5   8      128     503808 sdi   8      129       2160 sdi1   8      130     242304 sdi2   8      131     242304 sdi3   8      132          1 sdi4   8      133       8304 sdi5   8      134       8688 sdi6   9        9     530048 md9   9       13     458880 md13   9      256     530112 md256   9      322    7340032 md322

    Hi,
    ich kann Dir auch nicht sagen wie man das manuell wieder zusammenbaut, aber Du solltest noch mal die Ausgabe von mdadm --misc --detail /dev/md0 posten.
    Was Du oben angehängt hast ist m.E. nicht sehr aussagekräftig (bis auf die Screenshots).
    Was das Qnap gemacht hat weiss ich nicht, aber ein Raid5 mit 2 defekten Platten ist eigentlich hinüber!
    Ich hoffe Du hast eine vernünftige Datensicherung.
    Selbst wenn man noch 2 der 3 HDDs wieder mounten könnte, zutrauen hätte ich zum Raid nicht mehr.


    Gruss

    Hallo, Danke für die schnelle Antwort.


    Den o.g. Code hatte ich aus einem Topic mit ähnlichem Problem. Hier wusste der Fragende aber wie er das Raid wieder zusammenbaut. Daher fehlen diese Angaben.


    Deinen Code habe ich ausgeführt, aber mit wenig Erfolg:


    Code
    [~] # mdadm --misc --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory

    Ein Versuch ist es Wert den Festplattentausch durchzuführen, wenn man es wieder gemountet bekommt. Besser als 15 TB wieder neu aufzubauen.

    Upps, das sieht gar nicht gut aus, das NAS kennt das Raid nicht mehr!


    Normalerweise müssten dort die Angaben zum Raid stehen, auch wenn das Raid z.Zt. inactiv ist hätte ich aber diesen Status mit dem o.a. Kommando erwartet.
    Aber stimmt, in der Ausgabe von cat /proc/mdstat fehlt md0, da sollte das Raid5 stehen.


    Da musst Du doch warten bis sich jemand der sich in den Tiefen des Software Raids auskennt meldet und vielleicht eine zündende Idee hat.


    Gruss

    Trotzdem vielen Dank für Deine Bemühungen.


    Mit meinem Leienwissen gehe ich davon aus, dass das Raid neu gemountet werden muss. Denn oben sieht man ja, dass nur SDA1-5 da sind. 6-8 fehlen. Die Festplatten sind aber da, wie man im Screenshot sieht.


    Daher wäre der Befehl zum mounten des Raid gut.


    Es könnte auch sein, dass die Platine defekt ist. Denn es ist schon komisch, dass ab Platte 6 nichts mehr geht. Auch beim Neustart leuchten einmal kurz alle Lampen von 1-5 auf, 6-8 nicht. 6-8 leuchten erst später mit.


    Na warten wir mal ab, ob sich hier noch ein Experte meldet oder der Support von Qnap etwas machen kann.

    Hi,


    was war denn der Grund für die Warnung an Platte 8 und der Anormalität der Platte 6?
    Kann natürlich sein, dass das System nach dem Austausch von Platte 6 den Rebuild einleiten wollte und dann festgestellt hat, dass Platte 8 auch nicht mehr in Schuss ist.
    Dass die letzten drei Platten später zugeschaltet werdne bei Starten kann durchaus normal sein. Man will in der Regel nicht, dass alle Platten beim Start gleichzeitig anlaufen um Spannungsspitzen zu vermeiden.
    Interessant finde ich die Abweichung im QTS und in der Konsole. Deine Codeschnipsel sehen eigentlich so aus, als wäre jede Platte erkannt worden.
    Fahr doch mal die Kiste runter und stecke die Platten 7 und 8 neu. Die Platte 6, die ja offenbar schon aus dem Raid geflogen ist, würde ich draussen lassen bzw. durch eine der neuen Platten ersetzen (In einen Rebuild mit dieser Platte reinzugehen, erscheint mir nicht sinnvoll.)
    Wenn Du die Kiste dann startest, wie sieht dein Disk-Manager (nicht da wo die Raidgruppe angezeigt wird) aus? Gibt es bei irgendeiner der erkannten Platten den Knopf "Recover / Wiederherstellung"? Wenn ja, sollte man darüber mal den Status aller Platten neu einlesen.


    Falls das nicht hilft, was ist die Ausgabe von
    mdadm --examine /dev/sdX3 ?
    (Du musst diesen Befehl 8 Mal ausführen und X jeweils durch a,b,c,... ersetzen.)



    Mittels mdadm --assemble müsstest Du das md-Device vermutlich zusammenbauen und mit den LVM-Tools mounten können.
    Das wäre aber im Endeffekt nur sinnvoll, wenn man noch Daten von dem Raid retten müsste.
    Wie FSC830 schon geschrieben hat, würde ich dem Raid - Verbund auch nicht mehr unbedingt trauen und den neu aufbauen.

    Hallo,


    vielen Dank für Deine Antwort.


    Zunächst die SMART Fehler:
    Bei allen 3 Platten - Current Pending Sector und Uncorrectable Sector Count
    Wobei nur Current Pending Sector eine Warnung zeigt. Uncorrectable Sector Count steht auf gut.


    Runter fahren und mit neu gesteckten Platten wieder hochfahren führt zum gleichen Ergebnis. Platte 6 ist draussen, Platte 7 und 8 zeigen Fehler.
    Auf Wiederherstellung kann ich klicken, kann aber nur "Alle freien Laufwerke scannen" klicken. Und freie Laufwerke gibt es ja keine. Siee Screenshot.


    Die Code von Examine Code füge ich unten ein. Zusätzlich noch Screenshots vom Disk-Manager.


    Kannst Du mir den assemble Befehl genauer aufschreiben? Ich will nichts falsch machen.


    Danke und Gruß!

    Code
    [/] # mdadm --examine /dev/sda3 /dev/sda3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 56103643:d8a0001f:e9e81214:acf57de2    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : baaf09a8 - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 0   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdb3 /dev/sdb3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : acd227ed:fa89df14:7bb7979d:448cbdfa    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : fc441a4c - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 1   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdc3 /dev/sdc3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 29f22831:63dbbea4:81757f44:91844807    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : 83974185 - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 2   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdd3 /dev/sdd3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : da537ccc:7b93e410:b836cb73:9fc03aab    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : 5e4e9205 - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 3   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sde3 /dev/sde3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 45b3ebc8:a4f11f48:93e08d66:d0835dbe    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : 97de8336 - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 7   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdf3 /dev/sdf3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x8     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 7754261f:0cc05cd9:0da3193d:4bf8915b    Update Time : Sat Jan 27 15:43:41 2018  Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present.       Checksum : f31e2d90 - correct         Events : 696769         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 6   Array State : AAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdg3 /dev/sdg3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x0     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 1081b8df:ec3d7cbc:fcfe767d:37c4eaac    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : 287dfc1c - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 5   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)[/] # mdadm --examine /dev/sdh3 /dev/sdh3:          Magic : a92b4efc        Version : 1.0    Feature Map : 0x2     Array UUID : d74f4a1d:85e9e31d:4f4973ff:05f122a6           Name : 1  Creation Time : Sun Oct 30 01:01:14 2016     Raid Level : raid5   Raid Devices : 8 Avail Dev Size : 7794127240 (3716.53 GiB 3990.59 GB)     Array Size : 27279443968 (26015.71 GiB 27934.15 GB)  Used Dev Size : 7794126848 (3716.53 GiB 3990.59 GB)   Super Offset : 7794127504 sectorsRecovery Offset : 26106576 sectors   Unused Space : before=0 sectors, after=648 sectors          State : clean    Device UUID : 9fe59bb8:7d06a69e:5be94af0:ac39ade9    Update Time : Sat Jan 27 15:53:36 2018  Bad Block Log : 512 entries available at offset -8 sectors       Checksum : 94afe3e4 - correct         Events : 696770         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 4   Array State : AAAAAA.A ('A' == active, '.' == missing, 'R' == replacing)


    Screenshot 2018-01-28 20.36.04.pngScreenshot 2018-01-28 20.39.19.png



    Ich habe gerade folgendes gefunden:

    Zitat

    Controller-Fehler



    In Einzelfällen kann es vorkommen, dass aufgrund eines defekten Netzteils (oder Controller) ein RAID nicht mehr funktionsfähig ist. In so einem Fall liegt oft kein Schaden an den Festplatten vor und das Problem kann mit der folgenden Vorgehensweise behoben werden:

    • RAID stoppen:sudo mdadm --stop /dev/md0
    • Das RAID muss manuell wieder zusammengefügt werden, dabei ist es wichtig, die letzte funktionierende Konfiguration zu verwenden. Bei dem o.g. Beispiel, ein RAID 5 mit 4 Partitionen, bei dem zwei Festplatte wegen Controller-Defekt ausgestiegen sind, müssen die ersten zwei Partitionen verwendet werden, da sie bis zum Ausfall noch zusammen aktiv waren. Nun reaktiviert man das Arrays mit: sudo mdadm --assemble /dev/md0 /dev/sde1 /dev/sdf1 --force .
    • Die weiteren Partitionen können nun mit:sudo mdadm --re-add /dev/md0 /dev/sdg1 /dev/sdh1 wieder in den Verbund aufgenommen werden.

    Demnach müsste der korrekte Befehl in meinem Fall heißen:

    Code
    mdadm --stop /dev/md0mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 /dev/sdf3 /dev/sdg3 /dev/sdh3 --force

    Oder dem Beispiel weiter folgend:

    Code
    mdadm --stop /dev/md0
mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 --force
mdadm --re-add /dev/md0 /dev/sdf3 /dev/sdg3 /dev/sdh3

    Ist das so richtig? Kann ich dabei noch mehr kaputt machen?

    Pending Sectors bedeutet, dass die Festplatte nicht in der Lage war, einen Sektor zu lesen und hat sich den/die Sektoren vorgemerkt, sie durch "Reserve"-Sektoren zu ersetzen, sofern hier weiterhin beim Lesen Fehler auftreten - das ist dann gleichbedeutend mit dem Verlust der Information, die in den betroffenen Sektoren war.


    Die Wahrscheinlichkeit, dass dein Raid-Rebuild fehlschlagen wird, ist vergleichweise hoch, zumal ich vermute, dass die anderen Platten ähnlich alt sein werden und vermutlich beim gleichen Händler gekauft wurden (= gleiche Produktionscharge).


    Solltest Du daten retten müssen, probiere es mit


    Code
    mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 /dev/sdg3 /dev/sdh3 --force



    Beachte, dass die Platte 6 (sdf3) in meiner Auflistung fehlt. Sie ist nicht mehr synchron (und hat zudem eine Bad Block Markierung) mit dem Raid und daher für den Aufbau des Raids nutzlos.


    Den Stop-Befehl wirst Du dir sparen können, da es bei dir kein md0-Device gibt, dass es zu stoppen gilt.


    Für das Retten von Daten wirst Du vermutlich weitgehend auf die Konsole angewiesen sein - d.h. du wirst jetzt zwar das Raid-Device im degraded Mode gestartet haben, musst jedoch noch deine volume-Group etc. mounten.


    Klare Empfehlung: Baue ein neues Raid und spiele die Daten von deinem Backup zurück.
    Ich würde zudem in Erwägung ziehen, bei 8 Platten eher auf Raid 6 umzusteigen - denn 8 Platten in einer Gruppe bedeutet grundsätzlich auch die 8fache Wahrscheinlichkeit, dass eine Platte ausfällt.

    Vielen Dank.
    Scheint aber leider nicht geholfen zu haben.



    Code
    [/] # mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3  /dev/sde3 /dev/sdg3 /dev/sdh3 --force 
mdadm: failed to get exclusive lock on mapfile - continue anyway...
mdadm: /dev/md0 assembled from 6 drives and 1 rebuilding - not enough to start the array.

    Gleiches auch wenn ich die 6. Platte noch hinzufüge.


    Noch irgendeine Chance oder war es das? Ein paar Daten würde ich schon gerne noch sichern. Für das wichtigste gibt es natürlich Backups.


    Macht es Sinn als Platte 6 eine leere einzusetzen?

    Hm ich sehe grade, dass die Platte 8 das Feature Map auf 0x2 gesetzt hat. Da hat dann wohl während deiner Plattentauscherrei offenbar auf der Platte 8 tatsächlich ein Rebuild angefangen. Da auch die Bitmap auf deinem Raid ausgeschaltet war, macht das System jedes Mal einen vollständigen Rebuild wenn eine Platte aus irgendeinem Grund auch nur kurz aus dem Raid fällt.
    Man könnte zwar noch ein paar Dinge probieren und schauen, ob man zuindest einen Teil noch wiederherstellen kann- das übersteigt allerdings leider die Möglichkeiten, die ich per Ferndiagnose probieren möchte, da ich nicht abschätzen kann, in wie weit hier QTS-spezifische Anpassungen quer schießen könnten.


    Vieleicht hat der Qnap-Support hier noch ein Tool im Zauberhut...

    Mühsam ernährt sich das Eichhörnchen...


    Ich habe jetzt die 8. Platte rausgenommen und mit Platte 6 assembled. Und siehe da, wir haben ein Ergebnis:


    Code
    [/] # mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 /dev/sdf3  /dev/sdg3 --forcemdadm: failed to get exclusive lock on mapfile - continue anyway...mdadm: clearing FAULTY flag for device 5 in /dev/md0 for /dev/sdf3mdadm: Marking array /dev/md0 as 'clean'mdadm: /dev/md0 has been started with 7 drives (out of 8).


    Kannst Du damit was anfangen? Wie geht es weiter? In der Weboberfläche hat sich nichts geändert.
    Jetzt die 8. Platte hinzufügen? Oder kann man jetzt vielleicht schon auf die Daten zugreifen?


    Hier noch die Details:


    Da bin ich jetzt tatsächlich ein wenig (positiv) überrascht, dass die Qnap das mit der Platte 6 gemacht hat - ich hätte das nicht ohne ddrescue-Kopie o.ä. probiert.


    Aber theoretisch solltest Du das md-Device jetzt über den Umweg über LVM /volume groups (du hast ja ein Thick Volume) mounten können.
    Grundsätzlich müsst Du aber damit rechnen, dass alles, was Du von dem Raid kopierst, möglicherweise korrupt ist.
    D.h. alles, was Du auch von deinem Backup ziehen kannst, solltest Du dir lieber von dort ziehen.


    Der Mount-Vorgang wurde kürzlich schonmal besprochen - du kannst dich in
    diesem Thread entlanghangeln.

    Wow, Du bist ein Genie!
    Die Anleitung in dem anderen Thread war perfekt.


    Ich komme jetzt über Konsole in den Ordner und alle meine Daten scheinen noch da zu sein.
    Dann jetzt Backup machen.


    Dann schließe ich jetzt mal eine USB Platte an das NAS an und versuche die Daten zu retten.


    Oder gibt es irgendeine Möglichkeit den Ordner im Netzwerk auffindbar zu machen?

    Ich würde in dem derzeitigen Systemzustand einfach mit der USB-Platte arbeiten.
    Du könntest noch mit WinSCP versuchen, über das Netzwerk darauf zuzugreifen - vermutlich geht es mit USB-Platte aber schneller.

    USB-Platte hat super funktioniert.
    Alles prima, die ersten Daten waren schon gestern Abend drüben.
    Noch mal vielen vielen Dank für Deine Hilfe!


    Und WD tauscht die defekten Platten im Vorabtausch aus, so dass ich dann 30 Tage Zeit habe alles neu aufzusetzen und die defekten Platten zurück zu schicken. Also echt Glück im Unglück.


    Ich hoffe, dass dieser Thread mal irgendwem nutzt, der ein ähnliches Problem hat.