Sam Hopkins wrote:
Hello,
I have a client with a failed raid5 that is in desperate need of the
data that's on the raid. The attached file holds the mdadm -E
superblocks that are hopefully the keys to the puzzle. Linux-raid
folks, if you can give any help here it would be much appreciated.
Sam Hopkins wrote:
mdadm -C /dev/md0 -n 4 -l 5 missing /dev/etherd/e0.[023]
While it should work, a bit drastic perhaps?
I'd start with mdadm --assemble --force.
With --force, mdadm will pull the event counter of the most-recently
failed drive up to current status which should give you a
Having raid fail on friday evening is pretty bad timing - not there is
perhaps any good time for such a thing. I'm the sys-admin for the
machine in question (apologies for starting a new thread rather than
replying - I just subscribed to the list)
From my reading, it seems like maybe:
mdadm
Jonathan wrote:
# mdadm -C /dev/md0 -n 4 -l 5 missing /dev/etherd/e0.[023]
I think you should have tried mdadm --assemble --force first, as I
proposed earlier.
By doing the above, you have effectively replaced your version 0.9.0
superblocks with version 0.9.2. I don't know if version 0.9.2
Jonathan wrote:
I was already terrified of screwing things up
now I'm afraid of making things worse
Adrenalin... makes life worth living there for a sec, doesn't it ;o)
based on what was posted before is this a sensible thing to try?
mdadm -C /dev/md0 -c 32 -n 4 -l 5 missing
Well, the block sizes are back to 32k now, but I still had no luck
mounting /dev/md0 once I created the array. below is a record of what I
just tried:
how safe should the following be?
mdadm --assemble /dev/md0 --uuid=8fe1fe85:eeb90460:c525faab:cdaab792
/dev/etherd/e0.[01234]
I am
Jonathan wrote:
Well, the block sizes are back to 32k now, but I still had no luck
mounting /dev/md0 once I created the array.
Ahem, I missed something.
Sorry, the 'a' was hard to spot.
Your array used layout : left-asymmetric, while the superblock you've
just created has layout:
Jonathan wrote:
how safe should the following be?
mdadm --assemble /dev/md0 --uuid=8fe1fe85:eeb90460:c525faab:cdaab792
/dev/etherd/e0.[01234]
You can hardly do --assemble anymore.
After you have recreated superblocks on some of the devices, those are
conceptually part of a different raid
hazel /virtual # mdadm -C /dev/md0 -c 32 -n 4 -l 5
--parity=left-asymmetric missing /dev/etherd/e0.[023]
mdadm: /dev/etherd/e0.0 appears to be part of a raid array:
level=5 devices=4 ctime=Sat Apr 22 13:25:40 2006
mdadm: /dev/etherd/e0.2 appears to be part of a raid array:
level=5
Sam Hopkins wrote:
Hello,
I have a client with a failed raid5 that is in desperate need of the
data that's on the raid. The attached file holds the mdadm -E
superblocks that are hopefully the keys to the puzzle. Linux-raid
folks, if you can give any help here it would be much appreciated.
#
nice to hear you got your data back.
now it's perhaps a good time to donate some money to some
ppls/oss-projects for saving your ass ;) ;)
greets, chris
Jonathan wrote:
hazel /virtual # mdadm -C /dev/md0 -c 32 -n 4 -l 5
--parity=left-asymmetric missing /dev/etherd/e0.[023]
mdadm:
Molle Bestefich wrote:
Anyway, a quick cheat sheet might come in handy:
Which is why I posted about a wiki a few days back :)
I'm progressing it and I'll see if we can't get something up.
There's a lot of info on the list and it would be nice to get it a
little more focused...
David
--
On Saturday April 22, [EMAIL PROTECTED] wrote:
Jonathan wrote:
# mdadm -C /dev/md0 -n 4 -l 5 missing /dev/etherd/e0.[023]
I think you should have tried mdadm --assemble --force first, as I
proposed earlier.
By doing the above, you have effectively replaced your version 0.9.0
superblocks
Recreate the array from the constituent drives in the order you mention,
with 'missing' in place of the first drive that failed?
It won't resync because it has a missing drive.
If you created it correctly, the data will be there
If you didn't create it correctly, you can keep trying
14 matches
Mail list logo
