Jump to content
XPEnology Community

Volume crahsed


haydibe

Recommended Posts

Folgende Situation: als ich eben auf den Storage-Manage geschaut habe, wurden mir drei Platten als gecrashed angezeigt....

Ich habe auf Repair geklickt und nun werden 2 von 4 Platten als unbenutzt angezeigt.

 

Da ich nur ein SHR+1 angelegt hatte, gehe ich davon aus, dass nun alle Daten futsch sind...

 

Gibt es hier evtl. doch noch einen weg das Volume zu retten??

 

 

Link to comment
Share on other sites

die daten sind zum allergrößten teil noch da, die frage ist wie vile verlust man in kauf nehmen kann/will

jede raid platte hat einen sequenz counter, im normalzustand sind die alle gleich, werden daten nicht auf die platte geschrieben weicht der ab und die platten fallen aus dem raid

man kann sie mit den richtigen befehlen wieder in das raid "zwingen" aber es gehen dann eben diese nicht geschriebenen daten verloren bzw. haben falschen inhalt, was dann zu logischen fehlern in (wenigen) dateien führt, das sind evtl .nur ein paar hundert kB

erst mal wichtig ist die ursache zu ermitteln, an einem instabilen system sowas reparieren zu wollen geht meist schief

dann ermittelt man den sollzustand, layout der platten im mdadm raid, SHR bedeutet meist unteschiedliche platten waren in nutzung, was dann in mehreren raid sets endet die mit LVM zusammengefügt sind - SHR ist nicht so "speziell" es "nur" eine kombination auf linux standard sachen wie mdadm und lvm

nach dem dokumentieren ermittelt man die sequenz nummer und schiebt grade so viele platten wieder zurück in das raid wie nötig unf nimmt die platten mit der höchsten sequenz nummer, in deinem fall würde man von den 2 "freien" platten die sequenznummer ermitteln und nur eine mit der höchsten nummer wieder zum raid hinzufügen, da die chunk size meist 64k ist kann man am unterschied der plattten die noch synchron sind und der "besten" die man noch hat den verlust ermittlen, wenn man btrfs mit checksummen hat kann man evtl. sogar rausfinden welche dateien betroffen sind

 

lies mal hier rein und in den verlinkten englischen thread, da gab es noch bestehende hardware probleme was die reparatur (unter datenverlust) am ende doch verhindert hat

ist eigentlich nicht so schwer, flyride hat das in dem englischen thread sehr gut parallel zur reparatur erklärt, kann man fast als tutorial nehmen (setzt aber ein paar kenntnisse über linux und raid/lvm voraus)

 

https://xpenology.com/forum/topic/24767-asrock-j4105-itx-sata-controller-defekt/

 

Edited by IG-88
  • Thanks 1
Link to comment
Share on other sites

Ich vermute stark, dass es am Netzteil liegt und den großen Platten bei Lastspitzen der Saft entzogen wird.

Der Defekt ist bei einem HSR1 bestehend aus 4x 10TB WD RED aufgetreten, so dass die Hoffnung ist, dass hier der "einfache" Fall vorliegt.

 

Bei den Daten handelt es sich um einmal geschriebene, große Dateien - jeder Verlust kleiner 100% ist ein Gewinn ^^ Da ist es auch nicht weiter wild, dass das gecrashte Volume mit ext4 formatiert war.

 

Das mit der Sequenznummer ergibt Sinn und das man den "most recent" State wiederherstellt ergibt auch Sinn. Sobald das Volume wieder als stabil angesehen wird, kann man die vierte Platte dann ja wieder Problemlos hinzufügen.

 

Danke für den Link!

 

Ich werde mir das ganze Heute nach Feierabend mal zu gemüte führen. Wird schon wieder ein langer Tag :)

 

Link to comment
Share on other sites

Ich habe mir jetzt beide Threads durchgelesen, wobei der zweite schon eine ganz schöne Achterbahnfahrt war und deutlich komplexer/verbastelter als meine Situation. Ich denke der direkt verlinkte deutsche sollte bei mir passen. Vorher muss ich nur die Ursache mit dem Netzteil beheben - kommt am Mittwoch. Ich habe ein Dell T30 Mainboard, bei dem die Sata-Strom-Kabel vom Mainboard gespeist werden. Erstmal muss ein anständiges Netzteil her, um Mainboard und Sata Strom zu entkoppeln.

 

Wie beim verlinkten Thread is auch bei mir md2 betroffen.  Bei mir sind /dev/sda und /dev/sdc rausgeflogen. Spannenderweise hat /dev/sdc dieselbe Anzahl Events, wie /dev/sdb und /dev/sdd. Demnach dürfte ich sogar ohne Datenverlust davon kommen, wenn ich /dev/sdc wieder "reinzwinge" und später /dev/sda wieder hinzufüge.

 

Ich nutze den Thread mal als dokumentation für mich.

 

Überprüfung welches Laufwerk zu welcher Seriennummer gehört. Nach abgleich mit der UI ist klar sda und sdc wurde aus dem Pool entfernt.


root@dsm1:~# for drive in sda sdb sdc sdd; do echo "$drive: $(hdparm -I /dev/$drive | grep 'Serial\ Number')";done
sda:    Serial Number:      7JGALM9C
sdb:    Serial Number:      7JG98PTC
sdc:    Serial Number:      7JG93ZMC
sdd:    Serial Number:      7JG940AC

 


mdadm --detail /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Sun Oct  8 18:03:40 2017
     Raid Level : raid5
     Array Size : 29284796928 (27928.16 GiB 29987.63 GB)
  Used Dev Size : 9761598976 (9309.39 GiB 9995.88 GB)
   Raid Devices : 4
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sun Feb 16 23:12:35 2020
          State : clean, FAILED
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : dsm:2
           UUID : 0c601c7e:9112cec9:6592b3b4:e3808fca
         Events : 15581

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       1       8       21        1      active sync   /dev/sdb5
       -       0        0        2      removed
       4       8       53        3      active sync   /dev/sdd5

 

mdadm --examine /dev/sd[abcd]5 | egrep 'Event|/dev/sd'
/dev/sda5:
         Events : 15097
/dev/sdb5:
         Events : 15581
/dev/sdc5:
         Events : 15581
/dev/sdd5:
         Events : 15581

 

Bleibt am Mittwoch nur noch folgendes zu tun:


mdadm --stop /dev/md2

mdadm --assemble --force /dev/md2 /dev/sd[bcd]5

mdadm --detail /dev/md2

 

Neustart und dann im Storage Manager /dev/sda dem Pool einfach wieder zufügen.

 

@IG-88 danke für den Stupser in die richtige Richtung!

 

 

 

Edited by haydibe
Link to comment
Share on other sites

51 minutes ago, haydibe said:

Spannenderweise hat /dev/sdc dieselbe Anzahl Events, wie /dev/sdb und /dev/sdd. Demnach dürfte ich sogar ohne Datenverlust davon kommen, wenn ich /dev/sdc wieder "reinzwinge" und später /dev/sda wieder hinzufüge.

ja, das klingt erst mal sehr vielversprechend

 

53 minutes ago, haydibe said:

Überprüfung welches Laufwerk zu welcher Seriennummer gehört.

in dem 2. thread kam wohl noch erschwerend hinzu das die lsi sas controller (treiber) immer alle platten die gefunden werden direkt hintereinander klatschen so das wenn eine fehlt oder (wieder) dazu kommt sich jedes mal die buchstaben der sdX devices ändern, das kann ziemlich nervig sein wenn man sich nach jedem reboot neu orientieren muss

das passiert bei sata/ahci eigentlich nicht

 

58 minutes ago, haydibe said:

Neustart und dann im Storage Manager /dev/sda dem Pool einfach wieder zufügen.

ja das sieht erst mal alles richtig aus

wenn du das vor dem reboot noch mal begutachten willst dann wäre das /dev/md2 mit folgendem aktivierbar

 

mdadm --assemble --run /dev/md2 /dev/sd[bcd]5

danach könnte man mit "cat /proc/mdstat" und "mdadm --detail /dev/md2" prüfen ob das raid soweit ok aussieht

nach dem reboot kann man dann in der dsm gui einfach die platte der raid group hinzufügen oder sie als spare definieren, dann sollte sie kurz danach automatisch integriert werden

(letzteres kann bei shr2/raid6 notwendig sein wenn beide redundanz platten fehlen und man nur eine zum "hinzufügen" hat)

  • Thanks 1
Link to comment
Share on other sites

Zum Abgleich Laufwerk zu Seriennummer ist die Abfrage hier etwas galanter:

hdparm -I /dev/sd[abcd] | grep -E '(/dev|Number|1000)'

 

Wenn ich es richtig verstehe, kann ich direkt nach `mdadm --assemble` direkt booten, dann über die UI das letzte Laufwerk hinzufügen und dann die Kiste in Ruhe die letzte Platte in den Verbund aufnehmen. Oder muss ich mit dem Reboot solange warten, bis

mdadm --detail /dev/md2

etwas bestimmtes anzeigt?

 

(think) Irgendwie vermisse ich bei der Forensoftware "inline code" über Backticks oder [icode]...

Edited by haydibe
Link to comment
Share on other sites

55 minutes ago, haydibe said:

etwas bestimmtes anzeigt?

eigentlich nicht, im schlimmsten fall fährt er halt hoch und hat das raid nicht bereit und man schaut dann mit --detail nach

wenn man nach dem reboot sein volume in der gui als degraded wieder hat ist alles ok, man fügt die "freie" platte hinzu und der rest läuft von selbst

Link to comment
Share on other sites

Heute mit neuem Netzteil zeigt sich das Bild nochmal anders - für mich deutlich besser :)

 

Auf einmal ist /dev/sdc wieder Teil vom Array, das Volume startet wieder und alle Daten sind wieder da.

Ich konnte dem Storage Pool jetzt HDD1 aka sda wieder hinzufügen. Recovery ist in process.

 

Immerhin weiss ich jetzt beim nächsten Mal was zu tun wäre :)

 

Danke nochmal!

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...