Re: Wiederherstellung eines Raid10 bei Verlust von 4 von 6 Partitionen möglich?
Hallo Oliver,
zuallererst: ich bin sicher KEIN Profi für SW-Raid's, also nimm alle
meine Kommentare ausreichend vorsichtig ;-)
On Sat, Mar 05, 2011 at 02:24:34PM +0100, Oliver Linden wrote:
> Guten Tag,
>
> mir ist ein Raid10 Verbund, bestehend aus 6 Partitionen, auseinander
> geflogen. Die beiden weiteren Raid10 auf den gleichen Harddisks
> funktionieren noch!?
>
> Hardware:
> 6 1TB HD's von Samsung
> jede Platte mit einer primären 10GB und einer primären 6GB Partition
> versehen. Diese sind jeweils in einem Raid10 verbunden. Der Rest der
> jeweiligen Platten ist als eine erweiterte Partition mit ~984GB
> eingerichtet und diese sind ebenfalls in einem Raid10 zusammengefasst.
Wie genau sind denn die 6 Partitionen zusammengefasst? Du hast 984.20GB
pro Partition. Ich würde jetzt vermuten:
- je zwei Partitionen formen ein Raid 1: 984.2GB gespiegelt.
- diese drei Raid 1's hast du zu einem Raid 10 mit 3*984.2=2952.6GB
zusammengefasst.
Das heißt dann schon mal:
- Aus jedem der zweier-Paare darf genau eine Platte kaputt sein ==>
wenn 4 Partitionen weg sind, dann geht nichts mehr.
Allerdings scheinen die Festplatten ja noch alle zu funktionieren...
Also kann man es vielleicht retten...
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.651508] md: md2 stopped.
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.675260] md: bind<sda5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.675789] md: bind<sdc5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.675927] md: bind<sdd5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.676087] md: bind<sde5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.678580] md: bind<sdf5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.678782] md: bind<sdb5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.678804] md: kicking non-fresh sdf5 from array!
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.678811] md: unbind<sdf5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.692116] md: export_rdev(sdf5)
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.692181] md: kicking non-fresh sde5 from array!
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.692192] md: unbind<sde5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.704067] md: export_rdev(sde5)
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.704080] md: kicking non-fresh sdd5 from array!
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.704089] md: unbind<sdd5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.716058] md: export_rdev(sdd5)
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.716120] md: kicking non-fresh sda5 from array!
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.716128] md: unbind<sda5>
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.744058] md: export_rdev(sda5)
> Feb 16 19:57:48 HAM-XEN1 kernel: [ 1.760915] device-mapper: uevent: version 1.0.3
>
> So weit, so schlecht.
> Der Versuch, den Verbund mittels mdadm --assemble /dev/sd[a-f]5 wieder
> zusammenzufügen scheitert. Ein mdadm --examine /dev/sd[a-f]5 ergibt
> folgendes:
Das scheint mir etwas seltsam...
Bei allen sagt er:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 9326853a:28cc0a17:261d22f3:6258fc33
> Name : HAM-XEN1:2
> Creation Time : Wed Jan 5 23:56:04 2011
> Raid Level : raid10
> Raid Devices : 6
> Avail Dev Size : 1922265088 (916.61 GiB 984.20 GB)
> Array Size : 5766794448 (2749.82 GiB 2952.60 GB)
> Used Dev Size : 1922264816 (916.61 GiB 984.20 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : clean
> Update Time : Wed Feb 16 18:55:43 2011
> Layout : near=2
> Chunk Size : 4K
> Array State : .AA... ('A' == active, '.' == missing)
Also rein vom Speicherplatz her hat er 3*984.2GB -- das würde zu der
von mir vermuteten Struktur passen.
>
> root@Microknoppix:/var/log# mdadm --examine /dev/sd[a-f]5
> /dev/sda5:
> Device UUID : 212b9662:bffaa01c:222b200e:e5abe2ba
> Checksum : 48567961 - correct
> Events : 0
> Device Role : spare
> /dev/sdb5:
> Device UUID : 9c2d3357:15074540:5ab7d82b:4571851b
> Checksum : def2da66 - correct
> Device Role : Active device 1
> /dev/sdc5:
> Device UUID : e76a68e6:972c6d46:43e4796e:3d6617e6
> Checksum : 81835f17 - correct
> Events : 162
> Device Role : Active device 2
> /dev/sdd5:
> Device UUID : 5cb4c654:687a72eb:13327150:6eea6365
> Checksum : f62ac7bf - correct
> Events : 0
> Device Role : spare
> /dev/sde5:
> Device UUID : ed7703a0:68cb9773:bc4fd223:ad6f15a4
> Checksum : db9f7f38 - correct
> Events : 0
> Device Role : spare
> /dev/sdf5:
> Device UUID : bcf87c99:a95c7413:c2750aba:39b63c21
> Checksum : 8854fdda - correct
> Events : 0
> Device Role : spare
Allerdings hat er 2 aktive Platten -- die anderen sind alle "Spare".
Du könntest mal versuchen, was passiert, wenn du die Spare-Platten aus
dem Raid entfernst und wieder hinzufügst (also sda5, sdd5, sde5, sdf5):
mdadm /dev/md2 --fail /dev/sda5 --remove /dev/sda5
mdadm /dev/md2 --add /dev/sda5
Allerdings habe ich keine Ahnung, ob er dabei die Daten löscht???? Das
solltest du nochmal prüfen :-)
Was sagt denn bei Dir "mdadm --query --detail /dev/md2" über die exakte
Struktur? Wie sind die Platten zusammengebunden?
Axel
Reply to: