need help badly with RAID5 recovery

[bohnnyjliss]

23kb is a "large image"???? ok

this seems right, i guess i just need to let it scan.

ss1.png

[darkod]

Honestly I have never tried restoring like this, if you try to use software that tries to detect the whole array. Those 10TB are the whole array.

What I can give an advice about is the assemble of the array once you have the disks with the correct "old" partition tables. I thought you were gonna use testdisk to just get the layout back. In fact, if you knew the layout (numbers) you could even use sgdisk to "push" that as new partition table. But because you need to get it right it would be best if testdisk scan can point you the values when detecting what the old partitions start/end was. You said whole unpartitioned disks were used, so the layout might be very simple indeed.

But if you want to give this software a shot and try to restore the array as a whole (or the data from it, not sure what the software offers) you are free to try.

[bohnnyjliss]

Testdisk said it couldn't restore the old partitions

If this doesn't work I might have to go back to trying that

[darkod]

Even if it couldn't restore, did it at least show you some useful info? Like for example the old start/end of partitions?

And again I say, if whole disk was used maybe there were no partitions at all. Hence testdisk not being able to do a restore.

Anyway, if at least you have some info to work with, you can try a little risky process to produce a text file yourself that could act like "old backup" and tell sgdisk to use it to restore.

Because what sgdisk does when you use it to backup a partition table is basically dump info into a text file.

[bohnnyjliss]

It did tell me the start and end I don't know enough I guess on what to do. I'll post some more info Monday or something

[darkod]

OK. I might have spoken too fast about sgdisk. It seems the backup file it creates is binary coded, not simple text. So even if you know partition data you can't reproduce a file to simulate a backup file.

But there are other ways to try. When you create simple partition with parted or gdisk (without trying to create a filesystem at the same time!!!) I think it will only set the partition start and end without disturbing the actual data.

Once you post what you have we can see if something can be done about it.

You did clone the disks right? Do you have clones for trying out things without disturbing the original disks?

[bohnnyjliss]

i only cloned one of them at this point it takes 40 hours :/

filesystems did not get created on two of them, but the third it might have.

i should really try the freezer trick on the 4th drive that clicks

i tried it once but only left it in for a couple hours

[darkod]

Since it looks fairly certain that whole disks were used in the array, you could try the following. Your choice whether you want to try with the current (only) disks that you have or clones. Using clones gives you the possibility to keep the original disks as they are. But cloning takes time...

Another problem you have is that you only have two good disks out of four (I say good even if we ignore that the partition table was overwritten). So the best case for you is only two disks. You won't be able to re-assemble the array with that.

The disk where the OS was installed means it not only had the partiton table overwritten, but also new partitions created, formatted, AND files were written on them. Effectively overwriting part of the data that you want to have back.

Now depending how much was written into the disk, it would be only "small" portion of 4TB. Because the ubuntu OS is small.

So you could try the following:
1. Use parted to delete the partitions on all three disks (they had no partitions as raid members originally). DO NOT delete the partition table, just the partitions!!!
2. Try to use mdadm --create with --assume-clean to make a new raid5 with three members and one missing.

Obviously, even if the above works you will end up with part of the data corrupted (that was overwritten on one of the disks). But that's still better than losing all of the data.

Trying this is best on cloned disks, I go back to saying that...

If you wish to do that, let us know first and wait to double check the best command to use. You really didn't give us much to work with. Because mdadm might be sensitive to the disk order you use in the --create. And parameters like the chunk size, which according to your first post seems to have been 16M, not the usual 64K.

And I still don't understand something about your first two posts. If I understood correctly, all the damage (raid failure, OS reinstall over raid disk, wrong sgdisk -R usage) happened BEFORE this mess was handed over to you. Then how come you managed to pull what seems to be correct superblock info with mdadm -E /dev/sdc in your first post, and then immediately the second post had different output. But this is secondary now... What would have been good is to have few more superblock outputs so that we can figure out the disk order...

But if I understood correctly you can't provide any more correct superblock output for any disk.

[bohnnyjliss]

to clarify i was the one that accidentally sgdisk over the partitions, but i never created a filesystem or anything past that.

i got the mdadm -e info before i accidentally did that

i read the man wrong and had the partition copy backwards, i was going to try and copy the partition info from the "good" disk to the one that the previous person had tried to install linux (i believe not 100% sure, but thats what it seems like)

i'm DD'ing the two drives and i will try the assume clean when they are finished. i hooked them to faster connections and hopefully it will only take about a day to transfer both, they are going at the same time at about 60-70mb/sec

i'm also running a deep swearch using testdisk on one of the "good" drives and i will report back what partitions it finds.

[darkod]

If I'm not mistaken you already have one clone, you said earlier one has completed, right? Is that from sdc?

If you want to, you can try deleting the partitions on the clone, and we can see if that returns the mdadm superblock readable by any chance.

I don't think testdisk scans are useful on the disks. Because whole disks were used in mdadm there is no "partition layout" to detect...

I can understand the accident with sgdisk on one good disk, but what about the second one? You overwrote the partition table on both good disks?

I would try the --create --assume-clean as soon as you have the clones. At this time I see testdisk as something that is just taking you long time and not much usefulness.