Hello,
i now have a copy of sdb, but i dont know which of all these option i have to choose. if i run testdisk it found lot of old partition in quick search and a deep search founds a lot more and at all it cost hours of time and while this iam not sure if i choose the right to recover. while iam looking in the net for a solution i found some people who created new partition with gparted without formating and they could resuce the data, but all the steps are not logical and almost 2 years old. it whould be nice if some one could help quick.

I wish I knew where those instructions from rodsbooks didn't work for you. I completely obliterated my main GPT and the backup worked for me.

If you wish to keep trying to recover the GPT, you MUST work on the original unfortunately. The backup will have different properties that will cause recovery efforts to fail.

As you mention, you can recreate the partitions yourself, but you would need to know the exact geometry of those partitions. If you have that information, and are successful, yes you can recover that way (I've only done it with MBR however, but was successful - I don't see why it wouldn't work for GPT if you got it right).

Hello,
and thanks for your patience. The Problem is, that i dont know which command in which sequence to run.

If you are going at this yourself, you are gambling with the data that is left. from the way this sounds, your chances are well below 50%. Is this stuff of interest, or is it "must have"?

We have pointed you at the tools, you have internet access. It's unfair to Goumba or anyone else helping you to ask them to give an exact sequence of commands. That's your gamble, and your responsibility for the consequences.

If you would post the output from the quick search (use [CODE]...[/CODE] tags and not QUOTE tags, please), likely candidates could be found.

Before creating any "unformatted" partitions with gparted, please post what version of gparted you are using. Some versions had a bug that wrote a block of garbage to the partition.

Hi,
the outputThats the partition i created with parted. And gdisk has Version 0.8.5. A deeper search of this shows many partition from installation before. No one of them had a backup partition to restore.

I would use parted to delete that partition and then let testdisk see what it can find without any "clues" from an existing partition table.

When did you create that partition with parted? The sequence of events has been lost here, and it's very important. What I am understanding so far is that just before your error copying the partition table this disk had a single partition formatted ext4, and that a some time in its now irrelevant history it had been used in a RAID array. Did you then try to re-create the original partitioning with parted? If so, what parted command did you use? If it was mkpartfs you are in deep trouble because that builds a new filesystem and overwrites all of the filesystem metadata that was there before.
The problem I mentioned before was specific to certain versions of gparted, not gdisk. (I don't know whether parted itself was affected, or just the GUI version.)

i now added the partition with testdisk write the table and tried to mount the ext4, but got wront fs type and bad option or superblock. i think we start at the beginning. i make another backup from sdb. ok? And i dont have gparted only parted.

As he states, you're taking a gamble. You usually can't damage the data itself unless you get careless and start playing with tools that write data other than the partition table itself, but you have to know exactly what the tool is doing, and I'm guessing you won't.

I pointed you to the document I used, for manually recovering the partition table using the backup. Follow the steps described there, again, on the original drive (I know this is scary, but unfortunately you can't work on a backup with GPT, but at least you can use something like photorec on it as a last resort or write the backup back to the drive). Before you do so, make sure you protect that backup. Read the whole document before starting, it's of great help.

On original drive is very risky. But if i could make a backup with ddrescue and restore it if the recovery failed, it would be ok. I testet photorec on the backupimage and it found in the first 2 minutes a lot of files. the only problem is that the name is not the old one and there are a lot lot files with the same ending. so its no help for me

Doing it yourself, photorec is all you have got, I'm afraid. You were warned, you know. The ĺoads of files with the same name could easily be loads of _bits_of_ a few files if your disk was fragmented.

I understand it is risky, and I don't blame you. I just wanted to point it out as the following warning is on the recovery page I linked:

Not heeding this advice may cause you to waste a lot of time.

Sunghost, let me point out something.

For a customer, I ended up needing to copy an 800k disk written on a 720MB floppy that booted a CP/M machine back in the early 1990s. There followed a tussle with fdutils to determine disk format and many emails to the maintainer of fdutils, who was taken by my challenge. We unearthed an 80 track x 1k disc, and I believe he wrote the incident up as an example of how to use the things, and shoved it in the docs.

The point was, I could see the directory on this disk in a hex editor. It wasn't big. But I couldn't find the files, with only 80 tracks, 2 heads, and 5 sectors per track. What I was able to do was arrive with a laptop, configure the 1.44MB disk as 800k, dd in the last readable disk, and dd it out as often as he wanted.

What chance have you got on a 3 TB disk? Especially with partition data and probably root dir, perhaps even journal overwritten?

Ok you might be right but we are not in the 90s . But of course it is not simple, but i have hope while the data is there. So i now have sdb1 which is the problem disk with single partition ext4 sdb1. The partition table of this disk was overwritten with a disk member of a raid and had sdb1 sdb2 sdb3 and sdb4. After this mistake i take an identical disk, same model and partition (1 ext4 with 3tb) and overwrite the sdb and now i have this situation. Perhaps this make it clearer.

New is that i now have a second disk with 3tb and same model, so i could test with that, instead of an image on disk. What do you think? I will clone sdb to sdc, and test on sdc, ok? Should i special delete sdc before? Thanks so far for helping.