[LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) is an encryption specifications for Linux used to encrypt disk partitions. The
[cryptsetup](https://man.archlinux.org/man/cryptsetup.8.en) utility is usually used for that. After a partition is encrypted it can be opened for reading and writing after
> cryptsetup is used to conveniently setup dm-crypt managed device-mapper mappings. These include plain dm-crypt volumes and LUKS volumes. The difference is that LUKS uses a
> metadata header and can hence offer more features than plain dm-crypt. On the other hand, the header is visible and vulnerable to damage.
So after a partition is encrypted it has a LUKS header with some encryption metadata and a body. The header tells the program (cryptsetup) how to decrypt the partition. If that
header is damaged in any way then trying to decrypt it using `cryptsetup luksOpen /dev/sdx1` will print `Device /dev/sdx1 is not a valid LUKS device.` if the system is up-to-date.
On the server this happened the system was CentOS 7 with cryptsetup version 2.0.3 (as opposed to 2.6.1) so when I tried to decrypt it didn't prompt for a password and didn't print
anything. After upgrading the version following [this gitlab issue](https://gitlab.com/cryptsetup/cryptsetup/-/issues/783) I got it to print that message so I had something to
A good bit of googling led me to [this thread](https://bbs.archlinux.org/viewtopic.php?id=284768) on the Arch Linux forums. They describe the steps needed to diagnose most LUKS
problems. One thing that was different in this case was the command `sudo dd if=/dev/sdx1 count=20 | hexdump -C` printed only zeroes.
Testing with a larger block count `count=2050` showed that the first 2030 or so blocks were completely wiped. This meant that the LUKS header and possibly some of the data are
gone. This could still be fixed with a header backup file using `cryptsetup luksHeaderRestore <device> --header-backup-file <file>`.