Errors in Recovering Drive from Disk Image

Coarel · 2026-10-15 20:50:09

Hi all,

A week back, I lost my keyfile for my laptop's encrypted SSD, and after thoroughly searching, decided to give up and just re-install Arch on it. Before I did, I made a disk image backup of the entire disk (both the unencrypted boot and encrypted root partitions), just in case I found the keyfile. Well I found the keyfile (it was in the one place I didn't check) and now I have the task of restoring the disk and putting it back in my laptop. I thought this would be easy, but when I restored the image to the disk, the partition table was corrupt, and it couldn't be read. I made the disk image with GNOME Disk Utility and restored it also using that, so maybe there was some issue with that? I can try restoring it using another method, but I'd prefer not to since it takes a long time.

I tried a couple ways to restore the disk, starting with testdisk, which resulted in it finding this partition table, which looks correct (1GB EFI and 999GB LUKS partition)

Disk /dev/nvme0n1 - 1000 GB / 931 GiB - CHS 953869 64 32
Current partition structure:
Partition Start End Size in sectors
1 P EFI System 2048 2099199 2097152
2 P Linux filesys. data 2099200 1953525167 1951425968

When I saved it and restarted, the partitions showed up, however they were both labeled as 'unknown' by GNOME and Gparted, and couldn't be mounted.

I tried to at least recover the EFI partition using fsck.fat, but this returned an error

# fsck.fat -r /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
Logical sector size (2028 bytes) is not a multiple of the physical sector size.

I also tried to dump the LUKS header on the second partition, but that also returned an error

# cryptsetup luksDump /dev/nvme0n1p2
Device /dev/nvme0n1p2 is not a valid LUKS device.

Something else weird is that fdisk shows the disk identifier as all F's

# fdisk -l
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WD_BLACK SN770M 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p2 2099200 1953525167 1951425968 930.5G Linux filesystem

I also tried mounting the image as a loop device, but it gave me the same errors and same problems, so it's not a physical drive issue.

Please let me know what else I should try or if there is a known solution for this. I've looked around and I can't find anything about this specific issue.
This is my first post so please let me know if there's other information I should have added or if I've done something wrong.

jonno2002 · 2026-10-16 00:00:02

what happens if you run fdisk on the image itself:

fdisk -l /path/to/image.img

Coarel · 2026-10-16 03:24:19

I get a similar output to running fdisk on the drive

Disk /path/to/frameworkarch.img: 351.47 GiB, 377385880064 bytes, 737081797 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

Device Start End Sectors Size Type
/path/to/frameworkarch.img 2048 2099199 2097152 1G EFI System
/path/to/frameworkarch.img 2099200 1953523711 1951424512 930.5G Linux filesystem

jonno2002 · 2026-10-16 04:00:55

that image is only 351.47gb, the drive is 1tb, is that a compressed img file ?

file /path/to/image.img

even if it is compressed you said you used the same tool to backup and restore the image so it should have done it right.

if its just a bad partition table you can always re-create that and the actual data will still be there untouched.
try re-creating the partition table again and updating the luks header with the new UUID, all info can be found in the wiki, let me know if you get stuck.
just make sure you you create the exact same partition table as originally or things wont line up.

Coarel · 2026-10-16 04:08:30

I don't think it's compressed, I think it just shows as 351.47gb because that's how much of the drive I was using.

# file /path/to/frameworkarch.img
/path/to/frameworkarch.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x1,0,1), end-CHS (0x3ff,0,1), startsector 1, 737081796 sectors

If I'm reading this correctly, the partition table is definitely corrupted, not sure why why it's showing as DOS/MBR

I'll try re-creating the partition table and updating the LUKS header

jonno2002 · 2026-10-16 04:15:03

the thing about a disk image is that even if your only using 351gb the image will still be the size of the whole disk (1tb), thats why the wiki tells you to pipe dd through lz4 to keep the size of the image down. and also tells you to dump the fdisk output to a file as well just in case.
who knows what gnome disks does with its images, ive never used it
hopefully you can sort it and get all your data back.

cryptearth · 2026-10-16 06:01:21

do you remember what exactly you did when you noticed you lost the key file?
somehow this reads like you, by pure mistake, did something before the backup -> resulting in a bad backup in the first place
hopefully you're able to recover at least some of your data

seth · 2026-10-16 07:30:16

not sure why why it's showing as DOS/MBR

◉ sudo file -s /dev/nvme0n1                    
/dev/nvme0n1: DOS/MBR boot sector; partition …

That's just file.

But w/ https://gitlab.gnome.org/GNOME/gnome-di … _items/414 it doesn't look like GDU does compressed images

I think it just shows as 351.47gb because that's how much of the drive I was using.

du -h  /path/to/frameworkarch.img

If it's indeed smaller than 1TB the file was likely truncated - elsewise (gnome being stupid, you ran out of space on the the destination or removed/unpowered the backup device w/o syncing it)
And w/ an encrypted partition that's probably game-over

Except

when I restored the image to the disk, the partition table was corrupt, and it couldn't be read … I tried a couple ways to restore the disk, starting with testdisk, which resulted in it finding this partition table…

What are we actually looking at here? According to your OP the partition table could not be read, but you posted it.
Do you still have the *original* image?
How do you actually try to mount it and what are the exact errors you get?

Arch Linux

#1 2026-10-15 20:50:09

Errors in Recovering Drive from Disk Image

#2 2026-10-16 00:00:02

Re: Errors in Recovering Drive from Disk Image

#3 2026-10-16 03:24:19

Re: Errors in Recovering Drive from Disk Image

#4 2026-10-16 04:00:55

Re: Errors in Recovering Drive from Disk Image

#5 2026-10-16 04:08:30

Re: Errors in Recovering Drive from Disk Image

#6 2026-10-16 04:15:03

Re: Errors in Recovering Drive from Disk Image

#7 2026-10-16 06:01:21

Re: Errors in Recovering Drive from Disk Image

#8 2026-10-16 07:30:16

Re: Errors in Recovering Drive from Disk Image

Board footer