(Help) How to recover corrupted partition
- Anmelden oder Registrieren um Kommentare zu schreiben
I have a Luks encrypted partition, and with the help of my trusty footgun, I have accidentally overwritten the start of that partition. I don't know how many bytes I have overwritten, probably not much, but I can no longer unlock the partition.
Tools such as udiskctl don't recognize it as an encrypted device and gparted says the file system is unknown. So it's completely unusable now.
However I do have a Luks header backup.
Is it possible to recover the partition? And if so, how should I proceed?
It seems like this blog post is relevant: https://sebastian-reck.de/post/luks-cryptsetup-backup/
>"small section at the beginning of the partition, which is called the LUKS-Header."
>"imagine that this header section will get corrupted or destroyed for any weird reason. You failed a dd command or something like that. All of your data will be lost and you will not be able to decrypt your data"
And then it gives the command to restore the header, which is the same I've seen on other sites:
sudo cryptsetup luksHeaderRestore /dev/nvme0n1p2 --header-backup-file ./headerBackup.img
or as stated more generically elsewhere,
sudo cryptsetup luksHeaderRestore /dev/DEVICE --header-backup-file /path/to/backup_header_file
I've only read about it though, not restored one myself. It might be wise to wait and see if others weigh in with their experience on Trisquel.
Thanks for your answer. I tried to unlock the partition using the header backup file as a detached header, like this:
sudo cryptsetup -v --header /path/to/backup_header_file luksOpen /dev/DEVICE test
This command was successful. However, when I went to mount the unlocked device, I encountered the error "unknown filesystem type LVM2_member"
sudo mkdir /mnt/test
sudo mount /dev/mapper/test /mnt/test
Does anyone know what the problem might be or how to find out what the problem is?
When I look online there seems to be many potential causes of this error message, and I've seen people recommend using various commands like lvscan, vgrename, vgchange, and vgimportclone, none of which I am familiar with.
If I use these commands on a live system, is it correct to assume that won't change anything permanently? I don't want to make the situation any worse then it already is!
I'm assuming first of all you are going to back up your data to another drive while you've got it mounted like that? That would be my chief concern of course.
Do you have the 'lvm2' package installed? Are you in a live environment where you can open gparted and see what gparted says about it?
This comment looks useful, talking about using the 'udisksctl' command to control things: https://askubuntu.com/questions/63594/mount-encrypted-volumes-from-command-line/279218#279218
Thanks for the reply! I was using cryptsetup instead of udiskctl because this allows me to select a detached Luks header, which seems a less risky way of testing before restoring the Luks header. (I haven't seen any detached header option with udiskctl)
Actually, I remembered that I encountered the error with "unknown filesystem type LVM2_member" in the past and what works, for reasons I don't fully understand, is to mount one of the devices which shows up as /dev/dm-N instead of the named mapping created in /dev/mapper. So with this approach I am now able to successfully unlock and mount the partition.
My next step will be to use cryptsetup luksHeaderRestore, but I might wait a bit first, as you advised, just in case others with more experience weigh in.
It would also be interesting if I could somehow find out whether the tail of the corrupted Luks header is still intact or not, as this would tell me whether I maybe overwrote actual data on the partition past the end of the Luks header or not. Is there any way to examine the tail of the corrupted Luks header to see if it is still intact?
And while I am able to mount the unlocked partition using /dev/dm-N, I would nonetheless like to understand the reason why trying to mount the named mapping in /dev/mapper results in the error "unknown filesystem type LVM2_member", if anyone knows how this works, and how to solve this problem in a logical/elegant way, because mounting from /dev/dm-N seems like a not very logical workaround.