| 1 |
> md: bind<hdg2,1> |
| 2 |
> md: bind<hde2,2> |
| 3 |
> md: bind<hda2,3> |
| 4 |
> raid1: raid set md100 active with 3 out of 4 mirrors |
| 5 |
|
| 6 |
> md: bind<hdg5,1> |
| 7 |
> md: bind<hde5,2> |
| 8 |
> md: bind<hda5,3> |
| 9 |
> raid1: raid set md101 active with 3 out of 4 mirrors |
| 10 |
|
| 11 |
AFAICT this is all you need to know -- you definitely have two software |
| 12 |
(mdraid) RAID 1 volumes: |
| 13 |
|
| 14 |
md100 with hda2, hde2 and hdg2 as members |
| 15 |
md101 with hda5, hde5 and hdg5 as members |
| 16 |
|
| 17 |
Both arrays seem to have lost a member (I guess hdc2 and hdc5 respectively). |
| 18 |
|
| 19 |
Honestly I don't know what is the point of running RAID1 volumes with |
| 20 |
four mirrors, but that seems to be the way it was configured. |
| 21 |
|
| 22 |
I would suggest that you take a *single* disk (let's say hdg) out of the |
| 23 |
thing and hook it up to a fully functional Gentoo system with mdraid |
| 24 |
(and of course XFS) compiled in the kernel and sys-fs/mdadm installed. |
| 25 |
|
| 26 |
Then you can bring up each RAID volume in degraded state from the single |
| 27 |
mirror: |
| 28 |
|
| 29 |
#mdadm -A /dev/md100 -R /dev/hdX2 |
| 30 |
#mdadm -A /dev/md101 -R /dev/hdX5 |
| 31 |
|
| 32 |
(substiture hdX with the actual device name of the transplanted disk; in |
| 33 |
any case mdadm has a very useful man page) |
| 34 |
|
| 35 |
At this point you should be able to mount md100 and md101 *read-only* |
| 36 |
and salvage any data you need. |
| 37 |
|
| 38 |
Andrea |
Archives