dd-ed to wrong (luks)disk
 

It had to happen eventually.

I dd-ed a iso to the wrong hdd.

I realized my mistake after 10 seconds and hit ctrl-c to break it off but I was to late. It was a 8TB external luks-encrypted disk with one partition. At that time the 8TB disk was mounted and browsed true the files and all seems fine and i continued working on it. Until the next startup.

fdisk -l
fdisk -l /dev/sdb1
fdisk -l /dev/sdb2
dumpe2fs /dev/sdb
dumpe2fs /dev/sdb1
dumpe2fs /dev/sdb2
Info from gparted
If I could only go back in time to yesterday while it was still mounted and accessible I could have backed up the most important files....aaah. I had about half a dozen disks and i bought that 8TB disk to back up all the others who were not encrypted to encrypt them and put the data back. So I had all these little disks encrypted when the dd-disaster happened. Everything I have on data is on that 8TB disk. Loosing that is a atomic disaster.

As a complete noob in disk-recovery it seems only the first 2GB are effected. Is that where the headers are? Do I need to buy a new $280,00 8TB disk before trying to recover anything? I there any hope of recovering something?

TIA
Anton

Don't bother even trying. The LUKS header is in the first 2 to 4 MB of its partition. Once that has been overwritten and the LUKS volume is no longer open, there is no way whatsoever of recovering the master key that actually encrypts the data. Had you not rebooted, there would have been a way to extract that master key from the running kernel, but that opportunity is gone, and without a backup of that LUKS header there is now no way to recover anything from that 8TB disk.

I think you should consider that a definitive answer - rknichols has a good history of knowledge of this field.
Do you still have your old disks ? - you may be able to recover from those, even if somewhat out of date.

Yes I still have them.
 

Well that saves me $280,00 ;) Thanks for answering.

No, well .......yes, I still have them The whole point on buying that 8TB disk was (because they were not encrypted) to encrypt them and then put the data back but before I could do that the dd-disaster happened. Is it possible to remove the luks encryption from them and put the old partition back? I can’t remember with one was fat16, fat32, ext3 or ext4 partitioned. Can I try them all out without danger. Well I mean all is lost anyway so i can only gain from it? But is it possible and what course should I sail doing that?

You know it is all the fault of our stupid government, now we even have to buy a chip-reader for our id-card to go online for registering a phone-simcard. Nothing is private anymore. Osama bin laden is laughing in his grave!! And don’t even want to start about USA, NSA and globe-destroyer Trump. Sorry for my ranting. I don’t want to use Tails and encryption I just want to be left alone without the feeling someone is looking over my shoulder. Here in Belgium all your private data is connected to our personal tax-number even medical information.

And thank u for taking the time to help me.

Anton

Exactly what have you done on those old drives? If all you've done is a luksFormat operation (without the often recommended filling the drive with random data first), then almost all of the old content should be recoverable. One good thing is that you've now got a nice 8TB drive on which to save images of those old drives so that you can work on them safely.

The testdisk utility can be your friend here. It can identify the remains of many filesystems. But first, what is the state of those drives now? The output from "lsblk -f" (wrap it in [CODE] ... [/CODE] tags, please, to preserve formatting) might be the best way to show that.

I used the “disk utility” from Navigatrix (based on ubuntu 14.04) I’m pretty sure it did not fill the disks with random data.
In what format should I partition the 8TB disk?

The output from “lsblk -f” (wrap it in [CODE] ... tags, please, to preserve formatting) might be the best way to show that.

I don’t understand what you mean by this. What exactly do you want me to wrap in code tags? The output of lsblk -f (perhaps lsblk -f /dev/***) but how would that preserve formatting?

the wrapping means what did you do in your original post, I think.
The partition depends on you, you need to know how do you want to use that.

Just saying that you used some tool without saying what you did with it is not telling me very much. I can't download Navigatrix without registering, so I can't tell just what that distro is calling "disk utility". However, if you formatted a partition with a selection like "Encrypted + ext4", that would be very bad. Writing the initial metadata for an ext4 filesystem would seriously mutilate whatever had been on the disk before.

Now I come to think of it, I think I just deleted the files (not shredded) and changed the luks-passphrase on most of them . Maybe there is one where I deleted the partitions and made it one luks partition. I can't remember using "gnome-disk-utility 3.10.0-1ubuntu3" or "GParted 0.18.0" for deleting the partitions but I do remember to use disk-utility for creating luks and changing passphrase. Don't know if it matters but my system is 32bit.
But before we go any further I would like to setup this 8TB disk so I can use that for copying the other disks in to it. I will open a new thread for that for it is only sidelings related and others my benefit from it.

Anton

The only "disk utility"-like tool I find in Ubuntu 14 (and it's got to be the worst "disk utility" tool I've ever encountered) has only one action for setting up an encrypted partition, and that is, "Encrypted, compatible with Linux systems (LUKS + Ext4)". That does, in addition to setting up the encryption, format an ext4 filesystem in the container. Writing the blocks of ext4 metadata that are at the start of each block group in the filesystem is like firing a shotgun loaded with small birdshot at the data that was previously there. If you did that in addition to deleting the files, I don't hold out much hope for recovery. Merely using that tool to change a passphrase would not cause that problem, but back in post #4 you said:Again, if you would post the output from "lsblk -f" (it needs to be run as "root"), it would at least allow me to see what you have now. I think the best bet right now would be to use hexedit to obscure the LUKS header on any newly-created LUKS partitions (the first 4 bytes are ASCII "LUKS" -- perhaps change that to "SUKS") and then let testdisk see what remains of filesystems it can find on the drives. There's no point in doing that on partitions (if any) that really were previously encrypted.

lsblk -f
cryptsetup luksDump /dev/sdb
fdisk -l /dev/sdb

That is showing that you set up encryption on the entire device (/dev/sdb) and not just the partition (/dev/sdb1). Doing that wipes out the primary copy of the GPT partition table. Somehow this is not the same as what you posted in your other thread, where gparted is showing a valid encrypted partition /dev/sdb1 starting at sector 34 on the drive (the normal starting sector for the first partition on a GPT drive).