Again, I've had the same problem. I wrote a script to try recreating the array with every possible ordering of the drives. After each creation, I tried to mount the drive as ext3. When the mount succeeds, you've got a working array.

Sorry I don't have the script to show you but it's fairly straightforward. Create a drive order string by cycling through the various drives (including "missing") in each position, skipping drives that are already in the string. Create the array using the string and try to mount the device as ext3. Eventually you should get one that works.

With 11 drives (12 when you include "missing"), a brute force approach is going to be tedious but it should eventually work.

With 11 drives however, you should consider hot spares and/or RAID 6. Or replace all of your drives with larger ones to reduce the number of drives. The more drives in a RAID array, the greater the heat problems and the probability of drive failure.

OK, her's the script I have used successfully more than once. It can be easily modified for more or fewer drives. Note the nested for loops that need to be adjusted to match the number of drives you actually have. I've just had a need to use this script once again, so I know it works. It took less than a minute to salvage 2T of broken RAID5 array.

some notes:
- each for loop contains an if to prevent duplicate partitions from being used in a --create. If you have a lot of partitions in your array, this can get very awkward.
- you need a ./yes file containing the letter "Y" to feed the mdadm --create command or you get asked for a lot confirmations.
- the mdadm --stop command doesn't always work, so I've put it in a loop. The array must be stopped between attempts!
- I've put missing at the end of the drive list so that it will try to reconstruct using all the drives if possible

#! /bin/bash
drives="/dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2 missing"
mddevice="/dev/md1"
mountpoint="/home"

for a in $drives; do
for b in $drives; do
if [ "$b" != "$a" ]; then
for c in $drives; do
if [ "$c" != "$a" -a "$c" != "$b" ]; then
for d in $drives; do
if [ "$d" != "$a" -a "$d" != "$b" -a "$d" != "$c" ]; then
for e in $drives; do
if [ "$e" != "$a" -a "$e" != "$b" -a "$e" != "$c" -a "$e" != "$d" ]; then
echo attempting to create $mddevice with $a $b $c $d $e
if `mdadm --create $mddevice --level=5 --raid-devices=5 $a $b$ $c $d $e < ./yes`; then
if `mount -t ext3 $mddevice $mountpoint`; then
exit
fi
fi
while ! mdadm --stop $mddevice ; do
sleep 0.25
done
fi
done
fi
done
fi
done
fi
done
done

Sweet... I just got back from dealing with property issues in FL and will give that a try. Thanks so much once again! J

It's possible? That gives me a bit of hope. I know this thread is old, but it's the first that came up on google. So maybe somebody can still help me.

Short story, I've had a 3 disc RAID5 array, mdadm software raid. Two of the discs got their first 13.5 GB overwritten, the third one is fine.

Is there any way to recover the data? The discs are all 1 TB disc, so even tough the first 13.5 GB has gotton overwritten, the other 987.5 GB of data could be ok.

I've seen wonders done with RAID5 before, how would I go about making this miracle come to be?

Recovering data is a two-step process, although I'd advise you to work from copies of the original drives in all cases. You can get 1T drives for under $100, so how much is your data worth?

First, get the RAID array back up and running.

Second, use standard data recovery techniques to recover your files. This can vary depending on the file system you are using and the exact damage to the file system. The fact that you are dealing with a RAID5 array is not really relevant unless you were going to try a hardware recovery service.

In your case, overwriting 13.5G is pretty severe damage. I don't think it will be easy. Good luck.

yep... very true... making copies is invaluable... i wished i had the patience to wait for the replacement drives to arrive instead of starting the recovery process without making back ups =(

Okay, it was fixed, and all I lost was some large, old, files that could be easily restored from backup.

The way to go about this was to recreate the raid array with the assume clean option and the one good disk and one overwritten disk.

Then, add the third disk to the array and it will start to resync. This in itself is not enough, because a large part of the data is missing. However, since there was an LVM PV volume on this array, that information could be retrieved. Using the backup copies of the LVM information, I was able to recreate the exact same PV again.

Ran pvscan, vgscan and lvscan and my volumes where mountable again. Ran XFS chk on the mounted volume, it found about 13GB of 'problems', damaged video files mostly, but those could be restored from backup.

All in all, the recovery was speedy, succesfull and unexpected. Thanks for the help.

However, I do now have, once more, a refound respect for backups If I hadn't backed up the data, the loss would have been significant. Remember people, RAID is only your first line of defense and it's not a backup.

Thank you for the instructions.
I tried this on a raid 5 with 3 disks in my little NAS. One drive was acting up, and I pulled out another, so it was technically broken to one disk for some amount of time.
It did not boot up correct the next time.

So I made an image of each drive. dd if=/dev/... of=/dev/...

Then put my clone drives in the NAS and by shell I found the drives and used the command written a way back.
Well, this came out like the example. But the raid did not appear again in the web admin. The volumes were not there either, but it was rebuilding the third disk.

I was not sure how to mount this because I knew it had several partitions but they were not identified.

So, I uploaded a little file from cgsecurity called testdisk_static and made it executable. I ran the file and chose to analyze md0. This found the Linux LVM partition. So I made a prayer, then rebooted with hope that NAS mapper would find the md0 again and read the LVM.

All my data was back on line.

I give my many thanks to you authors and posters.

Hello , since this seems to be a popular thread in google i thought i'd share my solution to the problem.

Instead of recreating the array (possibility for errors if you set the wrong chunk size , or wrong devices), I just ran the below command -

mdadm --assemble /dev/md5 --uuid={UUID-of-raid5-array} --force

--force , will basically force the superblocks on drive components to "good" status and fix the RAID5 with no rebuild required.