Recover LUKS Partition using Testdisk

Some years ago I created an encrypted partition on an external drive. Recently the controller seems to have died and I tried a data recovery using Testdisk. There is one NTFS partition which I could recover. In Testdisk I can even see the LUKS partition as 2 partitions: one I can recognize as the LUKS header and the other seems to be some other partition that starts where hte LUKS header starts and end where the disk ends:

estDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sdb - 4000 GB / 3726 GiB - CHS 486401 255 63
     Partition               Start        End    Size in sectors
>* HPFS - NTFS              0  32 33 269464   5 45 4328937472 [Externe]
 D Linux                269464   5 46 269464  70 46       4096
 D Linux                269464   5 46 486397  33 36 3485030400

Question for me is,: How to recover this partition? It seems the data is there but how do I set up the partitions? Do I recover both? Only the first one?

you tried launching some disk utility?

gparted told me there is an issue with overlapping partitions. I thought it is because the NTSF partition ends on the same cylinder the LUKS partition starts but have since learned that it is supposed to be like that. gparted recognises the NTFS partition but sees the LUKS partition as unknown.

Have you tried to just open and mount the luks partition(s)?
So, just attach the drive to a linux computer and open the partition manually:

$ sudo cryptsetup luksOpen /dev/sdb3 my_crypt_part
$ sudo mount /dev/mapper/my_crypt_part /mnt
$ ls /mnt

(Where /dev/sdb3 is your encrypted luks partition. It might be somewhere else. If not sure, check with lsblk and replace /dev/sdb3 with the correct location).

Of course, the luksOpen command will ask for your password (the one for the encrypted drive).

It said it’s not a valid LUKS device

It’s very unusual that the LUKS header is in its own partition, perhaps the partition table got altered by some tool.
Post the output of lsblk -f and sudo blkid for that external disc.
Goal is to try address that header partition in the cryptsetup command separately, e.g.:

sudo cryptsetup open /dev/sdb3 my_crypt_part --header /dev/sdb2

I think this is just how Testdisk displays it. This is the output after having tried to restore the bottom partition from the Testdisk output further up.

lsblk -f                                                                 
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                         
├─sda1
│    ntfs         Wiederherstellung
│                       AEB07350B0731DD1                                    
├─sda2
│    vfat   FAT32       1473-F569                              70,1M    27% /boot/efi
├─sda3
│                                                                           
├─sda4
│    ntfs               76AA7CE8AA7CA5F1                                    
├─sda5
│    ntfs               4038CD1138CD073E                                    
└─sda6
     ext4   1.0         8eb86e52-fa90-4fb5-9996-29cacd80a4b1    1,1G    89% /
sdb                                                                         
├─sdb1
│    ntfs         Externe
│                       7C924AA4924A62AE                                    
└─sdb2
                                                                            
nvme0n1
                                                                            
├─nvme0n1p1
│                                                                           
├─nvme0n1p2
│    ntfs         schnell
│                       8EBC627BBC625DA9                                    
├─nvme0n1p3
│    ext4   1.0         f693fdf3-8c3d-49ce-a732-841bb4d07296  153,9G     0% /mnt/nvme0n1p3
└─nvme0n1p4
     swap   1           b83653fc-2978-47a7-9302-8b6a81f350d6      
~ >>> sudo blkid                                                                           
[sudo] Passwort für bumbum: 
/dev/nvme0n1p3: UUID="f693fdf3-8c3d-49ce-a732-841bb4d07296" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6f9fbd90-a856-42bf-9e64-0ac272a237c0"
/dev/nvme0n1p4: UUID="b83653fc-2978-47a7-9302-8b6a81f350d6" TYPE="swap" PARTUUID="2d8de9ed-7629-48f8-b44a-0c3134ee27dd"
/dev/nvme0n1p2: LABEL="schnell" BLOCK_SIZE="512" UUID="8EBC627BBC625DA9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="ba492a39-81cd-4af2-96c7-6d54ca6b4faa"
/dev/sdb1: LABEL="Externe" BLOCK_SIZE="4096" UUID="7C924AA4924A62AE" TYPE="ntfs" PARTUUID="70ef4873-01"
/dev/sda4: BLOCK_SIZE="512" UUID="76AA7CE8AA7CA5F1" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="6fe61115-9ba8-4adb-a1c7-e08cf22d5b11"
/dev/sda2: UUID="1473-F569" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a5f6a46e-8e77-492b-b831-78edde00b071"
/dev/sda5: BLOCK_SIZE="512" UUID="4038CD1138CD073E" TYPE="ntfs" PARTUUID="ba22d523-224d-482d-901c-0c3cf3c92d9f"
/dev/sda1: LABEL="Wiederherstellung" BLOCK_SIZE="512" UUID="AEB07350B0731DD1" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="119257ba-9e3d-4cbe-9bcb-b770d48e9ab8"
/dev/sda6: UUID="8eb86e52-fa90-4fb5-9996-29cacd80a4b1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a006a068-af8f-9745-a07d-9313a32aaa56"
/dev/nvme0n1p1: PARTLABEL="Microsoft reserved partition" PARTUUID="9de2155e-82a9-4981-933a-bd30c3de1f07"
/dev/sdb2: PARTUUID="70ef4873-02"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="d4c1c4c3-65bc-4788-b4ef-f7a211a3272f"

So, it’s one partition we look at, /dev/sdb2 in above output. cryptsetup will not recognise it like this anymore, no. A luks partition entry would have partition “TYPE=crypto LUKS” listed in both, lsblk and blkid.

Whatever you do now, don’t attach the disc while Windows is booted and ideally turn off Linux automount or change it to read-only for the external disc sdb.

I suppose this is after gparted’s “correction” of overlap you mentioned earlier. How did you try to restore it? What command did you run?

Does testdisc still recognise two Linux partitions like in your OP? If yes, we should try to write the supposedly header into a separate file (somewhere on sda) and see if cryptsetup recognises it as a --header.