• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

mdadm raid 5 keine superblocks mehr

error

Newbie
Hi,

ich habe ein RAID 5 Verbund (gehabt). Es konnte nicht mehr gestartet werden, weil ein Superblock weg war und das filesystem nicht mehr gelesen werden konnte. Dann habe ich gelesen, das die tolle möglichkeit besteht, alle Blöcke zu löschen mit zero-superblock. Habe ich getan (wohl mein größter Fehler?). Nachzulesen hier: http://kevin.deldycke.com/2007/03/how-to-recover-a-raid-array-after-having-zero-ized-superblocks/comment-page-1/#comment-6803

Naja, dann sollte ich einen neuen Verbund aufbauen und mdadm würde dann erkennen, das die Platten zu einem Verbund gehören und alles wieder frisch machen und den content behalten.

eine Platte hat jetzt wieder einen Superblock, die anderen nicht. Habe ich noch eine chance was zu retten?

Code:
debian:/# tune2fs -l /dev/sdb
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          319ae1ff-5c87-4d2f-b1bd-4152e2bf1fbe
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              183148544
Block count:              732571872
Reserved block count:     36628593
Free blocks:              61263574
Free inodes:              183002300
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      849
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Thu Mar 12 16:37:19 2009
Last mount time:          Thu Jan  7 17:28:51 2010
Last write time:          Sat Jan  9 10:03:02 2010
Mount count:              184
Maximum mount count:      25
Last checked:             Thu Mar 12 16:37:19 2009
Check interval:           15552000 (6 months)
Next check after:         Tue Sep  8 17:37:19 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      65279f15-a0ab-433c-90f6-97ba97f48aae
Journal backup:           inode blocks

RAID vorher:
Code:
debian:/dev# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Thu Mar 12 16:35:56 2009
     Raid Level : raid5
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Dec 31 20:48:40 2009
          State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 8f8d9f47:15d5e353:030e4bb8:1b229647
         Events : 0.430

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd

RAID jetzt (beim build wurde erkannt, das ein fs existiert, aber ich kann den verbund nicht mounten, weil kein fs erkannt wird):
Code:
debian:/share# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Jan  9 11:44:55 2010
     Raid Level : raid5
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Jan  9 11:44:55 2010
          State : clean, degraded
Active Devices : 3
Working Devices : 4
Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 68bd0dfd:29169258:71a8b18e:84df83c0
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       2       8       32        2      active sync   /dev/sdc
       3       0        0        3      removed

       4       8       48        -      spare   /dev/sdd
 
A

Anonymous

Gast
Du scheinst da vor lauter Superblöcken etwas durcheinanderzuhauen. Superblöcke gibts wie Sand am Meer. Das Raid an sich hat schon mal einen, aber jedes seiner Einzelteile hat auch was was sich Superblock nennt. Dein Filesystem selbst hat auch einen Superblock und jede Menge Kopien davon. Das Journal in deinem Filesystem hat auch nochmal einen Superblock. "Superblock" alleine ist nur ein Schimpfwort wie Chef, ohne eine genaue Zuordnung von was genau es der Superblock ist, oder zumindestens mit welchem Befehl du welchen "Superblock" siehst oder nicht siehst, ist mit dem Begriff Superblock nicht allzuviel anzufangen.

Das du irgendwelche Raid-Superblocke genullt hast und anschließend scheinbar wieder das Raid neu zusammengebaut hast war gelinde gesagt :zensur:
mdadm --detail /dev/md0
Sieht zwar bis auf das Hotspare und UUID erstmal noch so aus als würde es funktionieren, doch das muss noch überhaupt nichts heißen.
Die Unterschiedliche UUID zeigt schon mal das es nicht das selbe Raid ist was da am Ende herausgekommen ist.

Code:
tune2fs -l /dev/sdb
Was willst du denn damit, nachdem du das Raid aufgesetzt hast, hast du an den Einzelteilen vom Raid nichts mehr verloren. Für dich gibt es einzig und allein nur noch das Raid und keine Platten mehr. Der Befehl würde nach einem ext2/3/4 Superblock suchen. Nun gut den hat er jetzt wohl auf sdb irgendwo am Anfang gefunden, der steht aber bei dieser Raidgröße noch an 20 anderen Stellen irgendwo versteut auf den Platten. Du musst ihn aber auf /dev/md0 suchen, denn nur dort macht er einen Sinn, denn darauf ist dein Filesystem.

übrigens : das ist ganz schön leichtsinnig den automatischen Filesystemcheck zu deaktivieren :???: und nicht hin und wieder mal einen per Hand anzustoßen.
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 183148544
Block count: 732571872
Reserved block count: 36628593
Free blocks: 61263574
Free inodes: 183002300
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 849
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Thu Mar 12 16:37:19 2009
Last mount time: Thu Jan 7 17:28:51 2010
Last write time: Sat Jan 9 10:03:02 2010
Mount count: 184
Maximum mount count: 25
Last checked: Thu Mar 12 16:37:19 2009
Check interval: 15552000 (6 months)
Next check after: Tue Sep 8 17:37:19 2009

gib erstmal noch die komplette Ausgabe von folgenden Befehlen
Code:
mdadm --examine  /dev/sda /dev/sdb /dev/sdc /dev/sdd
cat /proc/mdstat
cat /etc/mdstat.conf
cat /proc/partitions
file -s /dev/md0
und die genauen mdadm Befehle die du abgesetzt hast vom "Nullen" der/des Raidsuperblöcke/s und vom zusammensetzen oder Neuaufsetzen des Raids und was du sonst noch mit den Raid angestellt hat, am Besten gleich aus der /root/.bash_history
ehr traut sich da sonst keiner auch nur einen einzigen Vorschlag zu machen, was du noch tun könntest.

robi
 
OP
E

error

Newbie
Code:
debian:/# mdadm --examine  /dev/sda /dev/sdb /dev/sdc /dev/sdd
/dev/sda:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 68bd0dfd:29169258:71a8b18e:84df83c0
  Creation Time : Sat Jan  9 11:44:55 2010
     Raid Level : raid5
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 5
Preferred Minor : 0

    Update Time : Sat Jan  9 11:44:55 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 251189a - correct
         Events : 1

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        0        0      active sync   /dev/sda

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb
   2     2       8       32        2      active sync   /dev/sdc
   3     3       0        0        3      faulty
   4     4       8       48        4      spare   /dev/sdd
/dev/sdb:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 68bd0dfd:29169258:71a8b18e:84df83c0
  Creation Time : Sat Jan  9 11:44:55 2010
     Raid Level : raid5
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 5
Preferred Minor : 0

    Update Time : Sat Jan  9 11:44:55 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 25118ac - correct
         Events : 1

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       16        1      active sync   /dev/sdb

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb
   2     2       8       32        2      active sync   /dev/sdc
   3     3       0        0        3      faulty
   4     4       8       48        4      spare   /dev/sdd
/dev/sdc:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 68bd0dfd:29169258:71a8b18e:84df83c0
  Creation Time : Sat Jan  9 11:44:55 2010
     Raid Level : raid5
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 5
Preferred Minor : 0

    Update Time : Sat Jan  9 11:44:55 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 25118be - correct
         Events : 1

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       32        2      active sync   /dev/sdc

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb
   2     2       8       32        2      active sync   /dev/sdc
   3     3       0        0        3      faulty
   4     4       8       48        4      spare   /dev/sdd
/dev/sdd:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 68bd0dfd:29169258:71a8b18e:84df83c0
  Creation Time : Sat Jan  9 11:44:55 2010
     Raid Level : raid5
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
     Array Size : 2930287488 (2794.54 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 5
Preferred Minor : 0

    Update Time : Sat Jan  9 11:44:55 2010
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 1
  Spare Devices : 1
       Checksum : 25118cc - correct
         Events : 1

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     4       8       48        4      spare   /dev/sdd

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb
   2     2       8       32        2      active sync   /dev/sdc
   3     3       0        0        3      faulty
   4     4       8       48        4      spare   /dev/sdd

Code:
debian:/# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (auto-read-only) raid5 sdd[4](S) sdc[2] sdb[1] sda[0]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]

unused devices: <none>

Code:
debian:/# cat /etc/mdstat.conf
cat: /etc/mdstat.conf: Datei oder Verzeichnis nicht gefunden

Code:
debian:/# cat /proc/partitions
major minor  #blocks  name

   8     0 1465138584 sda
   8    16  976762584 sdb
   8    32 1465138584 sdc
   8    48 1465138584 sdd
   3    64   78150744 hdb
   3    65   77497528 hdb1
   3    66          1 hdb2
   3    69     650601 hdb5
   9     0 2930287488 md0

Code:
debian:/# file -s /dev/md0
/dev/md0: X11 SNF font data, MSB first

Hier noch was ich getan habe...

Code:
mdadm --zero-superblock /dev/sd[abcd]

Code:
mdadm --create /dev/md0 --verbose --level=5 --raid-devices=4 --spare-devices=0 /dev/sda /dev/sdb /dev/sdc /dev/sdd
 
A

Anonymous

Gast
Sieht irgendwie böse aus. Alles andere ohne Garantie

ich nehme an da sind die wichtigsten Daten überhaupt drauf und keine Sicherung davon. Wenn doch, dann Sicherung überprüfen, Raid löschen und sauber neu anlegen und Sicherung zurück spielen.

Ansonsten, Daten gedanklich schon mal abschreiben, dann ist hinterher die Enttäuschung nicht so groß.

Was hier genau passiert ist, ist nicht zu sehen. Jedenfalls scheint die Platte sdb den Anfang des Filesystem zu haben. Das scheint mir auch logisch, da es die kleinste Platte ist. Wo hast du überhaupt so ein Platte her, ich kenne nur .. 9 18 36 73 146 und 300 SCSI Platten aber keine 98GB
Kann es sein das die Platten mal in ihren Plattensteckplätzen offline vertauscht wurden ?

Wenn du 4 x 146GB Platten oder eine große Externe übrig hast, dann mach zu allererst so wie sie jetzt sind von jeder eine physikalische Kopie oder ein Image davon, dann hast du ein paar Versuche mehr.

Auf keinen Fall die sdd Hotspare in das RAID einspringen lassen, bei einem Rebuild sind die Daten dann wahrscheinlich entgültig im Eimer.

Raid wieder auflösen. die Superblöcke noch mal löschen. und das RAID neu anlegen. Im Befehl ich würde persönlich ein Raid 5 mit 4 Platte und eine davon als "failed" angeben, (hotspare-Optionen komplet weglassen) und am besten die sdd erstmal ganz draußen lassen, damit er ja kein rebuild macht, und die sdb als erste Platte in der Reihenfolge angeben, andere Reihenfolge Glückssache.

Wenn das Raid steht, prüfen ob file -s /dev/md0 jetzt eine Filesystem findet und wenn, dann mit "fsck -n /dev/md0" erstmal nur testen ob das ein Filesystem geworden ist. Dein Filesystem hatte aber vorher schon Fehler also wird auch die Richtige Plattenreihenfolge wahrscheinlich einige Fehler melden.
Wenn es kein Filesyste ergibt das nur ein paar 100 "einfache" Fehler hat, dann solange Wiederholen bis du die richtige Reihenfolge hast. Erst dann einen richtigen Filesystemcheck machen. Wenn das funktioniert hat, dann die 4. Platte dazufügen und rebuilden.

Wenns nicht klappt dann von den Sicherungskopien alles wieder auf Anfang zurück und neue Idee oder Howto suchen.

Viel Glück - wirst du wohl brauchen.

robi
 
OP
E

error

Newbie
Erstmal danke für den Text. Es sind 1000 GB also 931 GB ganz normale SATA von WD. Aber das tut ja denke ich nix zur Sache.

Es sind die übelst wichtigsten Daten sowieso und ich wollte mal sichern, aber 3TB waren so groß, also wo hin damit? Und jetzt ist es zu spät, weil ich 300 Euro gespart habe.

Das RAID wie es war, entspricht nicht dem, wie es jetzt ist (Andre UID, andere Config (Spare war nicht gewollt, hatte spare=0 angegeben und es kam trotzdem eine), neuer Timestamp, nur das FS hat noch den create Timestamp von damals). Das macht mir bissle ungutes gefühl, da ich keine Spare benutzt hatte. Ich hatte 4 Platten aktiv.

Wie kann ich die Platte in ihrere Form spiegeln?
Wie kann ich die Spare funktion weg lassen? ich hatte 0 Spare angegeben, aber es hatte nicht gegriffen?
Wie kann ich den rebuild verhindern? Ich hatte Glück, das es noch nicht gestartet ist...
Ich würde mich sehr über Kommandos freuen. Ich weiß zwar was gemeint ist, aber am Ende mache ich noch mehr kaputt, weil ich falsche Kommandos abschicke.

Danke schonmal für die Hilfe
 
A

Anonymous

Gast
error schrieb:
8 0 1465138584 sda
8 16 976762584 sdb
8 32 1465138584 sdc
8 48 1465138584 sdd
Dann hatte ich mich wohl um eine Stelle verzählt, aber es sind wohl verschiedene Platten und die sdb ist die kleinst davon. Und auf dieser Größe aufbauend ist das Raid aufgebaut.

Wegen den Kommandos, ich muss mir da auch erstmal einen Versuchsaubau hinstellen und selbst ein bischen ausprobieren wie md-Raid sich verhält. Solche Geschichten macht man nicht alle Tage, und hier ein falscher Befehl und Daten entgültig pfutsch. Also mach erst mal Pause, ich spiel nachher noch ein bischen und dann morgen sehen wir weiter.

robi
 
OP
E

error

Newbie
Danke für die Mühe. Wie mache ich eine kopie von den Platten? Dann kann ich das schonmal tun.
 
A

Anonymous

Gast
Code:
* Ich hab jetzt mal 4 Dateien angelegt, wie bei dir eine kleiner als die anderen 3 und daraus loop-Devices gemacht.
* Aus den 4 loop habe ich ein Raid5 gemacht ein Filesystem darauf und ein paar Testdateien.
* Dann das Raid angehalten
* die Raidkennungen von den loopdevices entfernt 
* wie du das Raid wieder aufgesetzt
Soweit bist du jetzt, allerdings hat er bei mir das mit dem Sparedevice nicht gemacht, keine Ahnung was bei dir schief gelaufen ist, jedenfalls hat meins so wie ich das auch erwartet hatte, alles sauber funktioniert.
Code:
* Danach habe ich das Raid wieder angehalten
* die Raidkennungen von den loopdevices entfernt
* Wieder ein Raid 5 daraus gemacht , aber mit einer "missing" und in falscher Reihenfolge
* Das ganze mehrfach in verschiedener Reihenfolge probiert.
Bei einer falschen Reihenfolge ist das selbe Phenomen wie bei dir, aber Achtung, bei mir waren es 2 loopdevices die am Anfang eine Filesystemkennung hatten. (Nur eines davon kann wirklich der Anfang sein, das andere ist ein Checksummenblock, der genau dann auch als Filesystemanfang funktioniert wenn die andere Platte mit dem Filesystemanfan offline ist. Allerdings nur in der richtigen Reihenfolge) Als Wichtig beim Anlegen des Raids erachte ich dabei, das das kleine Device immer dabei ist, weil er sonst eine andere Raidgröße einrichtet, und dass immer ein "missing" dabei ist, damit er keinen Rebuild oder initialisierung machen kann. Dadurch werden keinerlei Daten auf dem Raid beschädigt egal wie das Raid falsch zusammengebaut ist. (zumindestens ist das mein Ergebnis aus diesem Tests) Die Option "--spare-device=0" bei dir am besten weglassen, keine Ahnung was du für eine md-Version auf den Rechner hast, scheint wohl ehr kein SuSE zu sein, eventuell ist dort ein Bug in deiner Version, kann man auch nie ausschließen besonders bei solchen Dingen die wenig benutzt werden wie zB Sparedevices. Getestet habe ich mit "file -s" auf das Raid und die einzelnen Loopdevices und "fsck -n" auf das Raid. ( "-n" Bedeutet hier, das er ohne weitere Optionen nur lesend zugreift, also nichts ändert, das ist wichtig bei der ganzen Geschichte.) sowie mit "mount -o ro " also immer nur lesend auf alles losgegangen.
Code:
* Wenn du die Richtige Reihefolge erwischt hast, funktioniert der "fsck -n"  ordentlich, sonst geht gar nichts oder es gibt dicke Fehler.
* Dann kannst du das Raid schonmal READONLY mounten
* Anschließend habe ich dann das "missing" noch ersetzt und dadurch das Raid wieder komplett gemacht
Hier jetzt mal die Liste der ausgefilterten Befehle die ich abgsetzt habe. Wenn du das gesamte Log von diesem Versuch haben möchtest sende mir bitte deine Mailadresse per PN. Das sind 670 Zeilen und etwa 24 KB und auch nicht so von allgemeinem Interesse das man das auch noch bei einem Hoster im Web ablegen und archivieren müsste. ;) .
Code:
rml100:/home/svuser # ls -l
rml100:/home/svuser # losetup /dev/loop1 disk1
rml100:/home/svuser # losetup /dev/loop2 disk1
rml100:/home/svuser # losetup /dev/loop3 disk2
rml100:/home/svuser # losetup /dev/loop4 disk3
rml100:/home/svuser # losetup /dev/loop5 disk4
rml100:/home/svuser # mdadm --create /dev/md1 --level=5 --raid-devices=4 /dev/loop[2345]
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mkfs.ext3 /dev/md1
rml100:/home/svuser # mount /dev/md1 /mnt
rml100:/home/svuser # cd /mnt
rml100:/mnt # ls
rml100:/mnt # for i in $(seq 1 500)
rml100:/mnt # ls -l
rml100:/mnt # cd
rml100:~ # umount /mnt
rml100:~ # mdadm --examine /dev/loop[2345]
rml100:~ # mdadm --stop /dev/md1
rml100:~ # cat /proc/mdstat
rml100:/home/svuser # mdadm --zero-superblock /dev/loop[2345]
rml100:/home/svuser # mdadm --examine /dev/loop[2345]
rml100:/home/svuser # mdadm --create /dev/md1 --level=5 --raid-devices=4 --spare-device=0 /dev/loop[2345]
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mount /dev/md1 /mnt
rml100:/home/svuser # cd /mnt
rml100:/mnt # ls
rml100:/mnt # cd -
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mdadm --stop /dev/md1
rml100:/home/svuser # mdadm --examine /dev/loop[2345]
rml100:/home/svuser # mdadm --zero-superblock /dev/loop[2345]
rml100:/home/svuser # mdadm --create /dev/md1 --level=5 --raid-devices=4 --spare-device=0 /dev/loop3 /dev/loop2 "missing" /dev/loop4
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mdadm --examine /dev/loop[2345]
rml100:/home/svuser # mount -o ro /dev/md1 /mnt
rml100:/home/svuser # file /dev/md1
rml100:/home/svuser # file -s /dev/md1
rml100:/home/svuser # file -s /dev/loop[2345]
rml100:/home/svuser # mdadm --stop /dev/md1
rml100:/home/svuser # mdadm --zero-superblock /dev/loop[2345]
rml100:/home/svuser # mdadm --create /dev/md1 --level=5 --raid-devices=4 --spare-device=0 /dev/loop5 /dev/loop4 "missing" /dev/loop3
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # file -s /dev/md0
rml100:/home/svuser # file -s /dev/md1
rml100:/home/svuser # file -s /dev/loop[2345]
rml100:/home/svuser # mount -o ro /dev/md1 /mnt
rml100:/home/svuser # fsck -n /dev/md1
rml100:/home/svuser # mdadm --stop /dev/md1
rml100:/home/svuser # mdadm --zero-superblock /dev/loop[2345]
rml100:/home/svuser # mdadm --create /dev/md1 --level=5 --raid-devices=4 --spare-device=0 /dev/loop2 /dev/loop3 "missing" /dev/loop5
rml100:/home/svuser # file -s /dev/md1
rml100:/home/svuser # file -s /dev/loop[2345]
rml100:/home/svuser # fsck -n /dev/md1
rml100:/home/svuser # mount -o ro /dev/md1 /mnt
rml100:/home/svuser # cd /mnt
rml100:/mnt # ls
rml100:/mnt # cd -
rml100:/home/svuser # umount /mnt
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mdadm --examine /dev/loop[2345]
rml100:/home/svuser # mdadm /dev/md1 --re-add /dev/loop4
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # cat /proc/mdstat
rml100:/home/svuser # mount /dev/md1 /mnt
rml100:/home/svuser # cd /mnt
rml100:/mnt # ls
Allerdings ist immer noch nicht klar was vorher bei dir schon kaputt war, was also der Auslöser für deine Aktion überhaupt war ?


robi
 
OP
E

error

Newbie
ich installiere mir grad auf einer VM in etwa das system, wie ich es als server habe und versuche das auch mal.
auslöser war wohl, das der rechhner sich einmal aufgehängt hatte und ich den ausschalten musste (ohne shutdown) und
dann war ein superblock wohl beschädift. danach habe ich gegoogelt und dann kam diese scheiss "--zero-superblock" geschichte bei raus.
ich melde mich wieder
 
OP
E

error

Newbie
okay, ich habe das mit einer vm mal nachgespielt und ein positives ergebniss erzielt. jetzt brauch ich hilfe beim kopieren der platten. wie kann ich die platten sicher kopieren, ohne daten zu verändern?
 
A

Anonymous

Gast
http://www.linupedia.org/opensuse/Dd#Beispiele_Clonen.2C_Backup_und_Sicherung dort "ganze Festplatte als Image ablegen / zurückschreiben" alles andere brauchst du nicht.

Wenn du sie als Image abgelegt hast kannst du sie auch mit loopdevice verbindest dann kannst du auch versuchen mit den Kopien das Raid wieder aufzubauen genau so wie ich das in dem Test gemacht habe, nur sind dann die Imagenamen das was bei meinem Test disk[1234] war. Dann bleiben deine orginalplatten von jegleichen weiteren Versuchen und Gefahren verschont

robi
 
OP
E

error

Newbie
Danke. Kann ich bei dd auch einen Status ausgeben lassen, wie weit der schon ist? Bei solchen größen dauert das ja schon ein bisschen.
 
A

Anonymous

Gast
error schrieb:
Danke. Kann ich bei dd auch einen Status ausgeben lassen, wie weit der schon ist? Bei solchen größen dauert das ja schon ein bisschen.

geht bei dd nicht, zwar bestände die Möglichkeit dem Prozess mit "kill -10 PID" (PID=ProzessID) den dd-Befehls ein Singnal zu senden das dd ermutigt den aktuellen Stand auszugeben was er bisher kopiert hat, halte ich aber für nicht ganz stabil in einigen dd-Versionen und desshalb riskant.

robi
 
OP
E

error

Newbie
ich habe eben noch was ausprobiert. ich habe 4 virtuelle laufwerke und damit ein raid-5

dann habe ich alles gestoppt und ausgehängt.
danach die sdd auf eine weitere platte kopiert per dd
ich dachte mir, der zustand muss ja gleich sein. mdadm meldet aber sde superblock missmatch (nicht wortwörtlich)
also zero superblock auf sd[abce]
neues array create auf abce
startet wunderbar. nur das die testdateien im arsch sind. uff?
 
A

Anonymous

Gast
Wenn du ein Raid 5 mit 4 devices neu aufsetzt und gibst dort kein "missing" an, dann läuft sofort eine Initialisierung und die Datein sind weg, desshalb immer nur angeben Raid 5 mit 4 Devices aber nur 3 mitgeben und für das 4. ein Missing angeben, dann kann er das Raid nicht neu initialsieren( also die volle Raidfunktionalität auf allen Devices herstellen) und die Daten auf den Devices bleiben erhalten. Das so erstellte Raid hat dann zwar keine Ausfallsicherheit, aber die Daten auf den Platten sind noch ok, Nur musst du eben die 3 richtigen Platten in der richtigen Reihenfolge (auch die missing muss an der richtigen Stelle sein), damit die alten Daten auf dem Raid ok sind.

Ein wieder onlinesetzten eines defekten oder herunterfefahrenen Raids geht auch, aber dazu müssen die Raidsuperblöcke auf allen Devices da sein und auch schlüssig sein. In dem Fall hier sind aber genau diese Blöcke immer ausgenullt also leer.

robi
 
OP
E

error

Newbie
wenn ich

Code:
mdadm -E /dev/sda

eingebe und ein superblock noch da ist, bekomm ich ja schöne infos. bekomme ich die auch aus backup superblöcken? bzw kann ich die noch irgendwie lesen, wenn ich --zero-superblock genutzt habe?
 
OP
E

error

Newbie
ich habe jetzt versucht, das ganze nochmal zusammen zu setzen. mit folgendem ergebniss:

Code:
debian:/share# mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd missing
mdadm: /dev/sdb appears to contain an ext2fs file system
    size=-1364679808K  mtime=Thu Jan  7 17:28:51 2010
mdadm: largest drive (/dev/sdc) exceed size (976762496K) by more than 1%
Continue creating array? y
mdadm: array /dev/md0 started.

Code:
debian:/share# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (auto-read-only) raid5 sdd[2] sdc[1] sdb[0]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]

unused devices: <none>

Code:
debian:/share# mount -o ro /dev/md0 /mnt/md0
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Code:
debian:/share# dmesg | tail
[ 9620.284047] raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2
[ 9620.284047] RAID5 conf printout:
[ 9620.284047]  --- rd:4 wd:3
[ 9620.284047]  disk 0, o:1, dev:sdb
[ 9620.284047]  disk 1, o:1, dev:sdc
[ 9620.284047]  disk 2, o:1, dev:sdd
[ 9639.233234] EXT3-fs error (device md0): ext3_check_descriptors: Inode bitmap for group 14380 not in group (block 471269376)!
[ 9639.233248] EXT3-fs: group descriptors corrupted!
[ 9887.381389] EXT3-fs error (device md0): ext3_check_descriptors: Inode bitmap for group 14380 not in group (block 471269376)!
[ 9887.381403] EXT3-fs: group descriptors corrupted!

Code:
debian:/share# mount -o ro -t ext3 /dev/md0 /mnt/md0
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Code:
debian:/share# fsck -n /dev/md0
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Gruppen-Deskriptoren scheinen defekt zu sein... versuche es mit Backup-Blöcken...
/dev/md0 wurde nicht ordnungsgemäà ausgehängt, Prüfung erzwungen.
Durchgang 1: Prüfe Inodes, Blocks, und GröÃen
Inode 7 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #1040929 (2147487744) in Inode 7.  IGNORIERT.
Inode 7, i_Blocks ist 149432, sollte sein 149640.  Repariere? nein

Inode 372 ist in Benutzung, aber hat dtime gesetzt.  Repariere? nein

Inode 372, i_Blocks ist 4096, sollte sein 0.  Repariere? nein

Inode 4404 ist in Benutzung, aber hat dtime gesetzt.  Repariere? nein

Inode 4916 ist in Benutzung, aber hat dtime gesetzt.  Repariere? nein

Inode 129494 ist in Benutzung, aber hat dtime gesetzt.  Repariere? nein

Inode 573406 ist in Benutzung, aber hat dtime gesetzt.  Repariere? nein

Inode 573406, i_Blocks ist 2806186078, sollte sein 0.  Repariere? nein

Inode 884760 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #453 (2062033159) in Inode 884760.  IGNORIERT.
Illegal(er) Block #454 (1881352789) in Inode 884760.  IGNORIERT.
Illegal(er) Block #455 (1946510426) in Inode 884760.  IGNORIERT.
Illegal(er) Block #457 (2383106727) in Inode 884760.  IGNORIERT.
Illegal(er) Block #458 (3410923588) in Inode 884760.  IGNORIERT.
Illegal(er) Block #459 (2526628719) in Inode 884760.  IGNORIERT.
Inode 884760, i_size ist 142927, sollte sein 1871872.  Repariere? nein

Inode 884760, i_Blocks ist 288, sollte sein 296.  Repariere? nein

Inode 884943 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #167 (1120398403) in Inode 884943.  IGNORIERT.
Illegal(er) Block #168 (1776504029) in Inode 884943.  IGNORIERT.
Illegal(er) Block #169 (3517570202) in Inode 884943.  IGNORIERT.
Illegal(er) Block #170 (2227789164) in Inode 884943.  IGNORIERT.
Illegal(er) Block #171 (1380051869) in Inode 884943.  IGNORIERT.
Inode 885032 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #733 (3796720728) in Inode 885032.  IGNORIERT.
Illegal(er) Block #736 (3482055632) in Inode 885032.  IGNORIERT.
Illegal(er) Block #737 (3214062129) in Inode 885032.  IGNORIERT.
Illegal(er) Block #738 (1671820555) in Inode 885032.  IGNORIERT.
Illegal(er) Block #739 (3735353680) in Inode 885032.  IGNORIERT.
Inode 885032, i_size ist 142540, sollte sein 3014656.  Repariere? nein

Inode 885032, i_Blocks ist 288, sollte sein 304.  Repariere? nein

Inode 885087 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #373 (2639157235) in Inode 885087.  IGNORIERT.
Illegal(er) Block #375 (2052909165) in Inode 885087.  IGNORIERT.
Illegal(er) Block #376 (3174324203) in Inode 885087.  IGNORIERT.
Illegal(er) Block #377 (2919910693) in Inode 885087.  IGNORIERT.
Illegal(er) Block #378 (3249609402) in Inode 885087.  IGNORIERT.
Illegal(er) Block #379 (745697405) in Inode 885087.  IGNORIERT.
Inode 885087, i_size ist 133100, sollte sein 1536000.  Repariere? nein

Inode 885087, i_Blocks ist 272, sollte sein 280.  Repariere? nein

Inode 885091 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #761 (2597684260) in Inode 885091.  IGNORIERT.
Illegal(er) Block #762 (1787272976) in Inode 885091.  IGNORIERT.
Illegal(er) Block #763 (1380761311) in Inode 885091.  IGNORIERT.
Inode 885091, i_size ist 132359, sollte sein 3117056.  Repariere? nein

Inode 885091, i_Blocks ist 272, sollte sein 280.  Repariere? nein

Inode 885113 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #640 (2073301267) in Inode 885113.  IGNORIERT.
Illegal(er) Block #641 (2262124834) in Inode 885113.  IGNORIERT.
Illegal(er) Block #642 (4249554037) in Inode 885113.  IGNORIERT.
Inode 885113, i_size ist 147551, sollte sein 2637824.  Repariere? nein

Inode 885113, i_Blocks ist 304, sollte sein 320.  Repariere? nein

Inode 885162 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #118 (2937300420) in Inode 885162.  IGNORIERT.
Illegal(er) Block #119 (3704537866) in Inode 885162.  IGNORIERT.
Illegal(er) Block #120 (902837556) in Inode 885162.  IGNORIERT.
Illegal(er) Block #121 (3427543722) in Inode 885162.  IGNORIERT.
Illegal(er) Block #122 (2688369999) in Inode 885162.  IGNORIERT.
Illegal(er) Block #123 (2890315979) in Inode 885162.  IGNORIERT.
Inode 885271 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #959 (1886862221) in Inode 885271.  IGNORIERT.
Illegal(er) Block #960 (2877708986) in Inode 885271.  IGNORIERT.
Illegal(er) Block #961 (4089405910) in Inode 885271.  IGNORIERT.
Illegal(er) Block #962 (893564042) in Inode 885271.  IGNORIERT.
Inode 885271, i_size ist 133667, sollte sein 3948544.  Repariere? nein

Inode 885271, i_Blocks ist 272, sollte sein 288.  Repariere? nein

Inode 885355 hat unzulässigen Block(s).  Bereinige? nein

Illegal(er) Block #-1 (4259331512) in Inode 885355.  IGNORIERT.
Fehler beim Iterieren über Blocks in Inode 885355: Illegal indirect block found
e2fsck: abgebrochen

wo stehe ich nun? ich will fsck nicht drüber laufen lassen, wenn ich mir nicht 100% sicher bin, das die reihenfolge der devices richtig ist (beim create vom mdadm), weil danach ist alles im arsch
 
A

Anonymous

Gast
Was du hier oben hast ist meiner Meinung nach ein normaler Defekt wie er nach einem Absturz auftreten könnte.
7 Inode sprich Dateien defekt, das waren Dateien die offen waren und nicht sauber fertig geschrieben werden konnten. Die restlichen defekten Blockmarkierungen sind wahrscheinlich auch unkritisch, das sind mit Sicherheit irgendwelche Blöcke am Ende von Dateien.

Wenn das alles ist, was er anmeckert dann würde ich es riskieren. Unten steht aber Abbruch, ich bin mir nicht sicher ob das wirklich das offizielle Ende der Liste ist, oder ob du oder fsck abgebrochen hat weil es keinen Sinn macht. Es ist sehr schade das er da vorne anmeckert das die Blockdisktriptoren vom Filesystemsuperblock defekt sind. Damit wird es mir zu kompliziert dir zu erklären wie du mit dem Filesystemdebugger mal in das Filesystem schauen könntest.

Es ist halt kompliziert, da irgendwo schlägt der alte Fehler und das Ausschalten des Rechners mit rein, und das macht die Sache recht kompliziert. Wenn der ursprüngliche Fehler ähnlich ausgesehen hat, dann sollte das wohl so sein. Wenn das das beste Ergebniss sein sollte das du bekommen kannst, dann riskiere es, wenn du noch nicht alles durchprobiert hast, dann schau erst mal ob du noch eine andere Kombination findest, die am Anfang keine kaputten Blöcke meldet.

Ich kann das von hier aus nicht eindeutig bestimmen.


robi
 
OP
E

error

Newbie
okay danke. ich riskiere mal eine andere zusammensetzung und fsck -n und werde dann posten. danke soweit.

nebenbei habe ich nicht abgebrochen, das kam von alleine nur bis dahin. hat mich auch gewundert, das es nur so wenig ist.

edit: andere kombination bring ein synchrones raid mit folgendem mount

Code:
mount: you must specify the filesystem type

ich denke, ich habe dann die richtige reihenfolge vorher getroffen, was?
 
A

Anonymous

Gast
Wenn du keine andere Kombination finden solltest, dann nimm die von vorhin wieder aber teste bitte bevor du mit fsck entgültig reparieren läßt, noch mal folgendes um sicher zu gehen. Folgende Befehle greifen nur lesend auf das Filesystem zu und testen ob Kopien des Filsystemsuperblocks die sich im inneren des Filesystems befinden, funktionieren. Sollte bei dir wirklich der erst Superblock einen Treffer abbekommen haben.
Code:
debugfs /dev/md0 -s32768 -b4096 -R "ls -l <2>"
debugfs /dev/md0 -s98304 -b4096 -R "ls -l <2>"
debugfs /dev/md0 -s163840 -b4096 -R "stats"

die ersten beiden sollte mit den Filesystemdebugger jeweils das unterste Direktory dieses Filesystems auflisten. Und dabei die erste und zweite Kopie des Filesystemsuperblock als Grundlage nehmen. Der dritte Befehl zeigt die 3. Kopie des Filesystemsuperblocks, sollte das funktionieren dann ist davon auszugehen das du richtig liegst. Achtung die Ausgabe könnte jeweils etwas länger sein, dann ist "less" als pager aktiv, beenden des Befehls dann normal mit "q"

wenn das obrige funktioniert kannst du auch diese Superblocke dann als Grundlage für den Filesystemcheck hernehmen
Code:
fsck.ext3 -b 163840 -B 4096 /dev/md0

robi
 
Oben