Recover corrupt data from LUKS partition?

After a data loss, I’m trying to restore files from a backup I made a few days ago on a LUKS-encrypted external drive. I now found that some of the files on the backup are corrupt - text files for example contain random binary data. I’m not sure how this happened in the first place. (I created the backup with rsync).

The physical drive is /dev/sdd1. The LUKS device is /dev/mapper/luks-{hex string}.

Any ideas for recovering this data? I was thinking fsck, but I don’t know how to apply that to a LUKS encrypted partition. Thanks!

If you have header backup, restore from file:

cryptsetup luksHeaderRestore /dev/DEVICE --header-backup-file /path/to/backup_header_file

If not then create header backup (in case if repair broke something you can restore with above command) and try repair:

cryptsetup luksHeaderBackup /dev/DEVICE --header-backup-file /path/to/backup_header_file
cryptsetup repair /dev/DEVICE

If you can open luks container without problem, run fsck:

cryptsetup luksOpen /dev/DEVICE LUKSNAME
fsck /dev/mapper/LUKSNAME

You made a backup (using rsync) TO an LUKS encrypted drive - correct?

you can access that backup once you opened the LUKS encrypted container
which holds the filesystem
which now holds your backup.

and only some files in that backup are corrupted - while others are fine?
(probably because they already where corrupted prior to transfer
or corrupted during transfer)

In this case: no - the files cannot be recovered without the original, hopefully undamaged, files.

This has nothing to do with the backup being on an encrypted device - if the situation is how I understood it.

1 Like

Agreed. This is more concerning than the fact that you’re using LUKS and encryption.

Only some files are corrupt?

The files that are “corrupt”, are they also corrupt on the source?

FYI: rsync checks “chunks” of each file, after they’re transferred, to make sure they are identical. It’s likely that the files were already “corrupt” prior to using rsync, as @Nachlese explains.

Time out.

Rewind a bit.

What is the context surrounding this?

What do you mean “data loss”?

Did you accidentally delete files?

Face a hardware issue?

Notice corruption on your source?

You made a “backup” a few days ago, from scratch? Or a quick incremental backup of only a handful of changes?

1 Like

By data loss, I mean I accidentally deleted the originals. It was a stupid thing, but it happened. :slight_smile: A few days earlier, I had made an original (not incremental) rysnc backup which at the time seemed completed without errors. (Later that day, my system froze and I had to do a hard reset while the backup drive was mounted. Perhaps that caused a problem.)

Now that I’m trying to restore the files from backup, I see that many, though not all are corrupt. There is for example a folder scripts with 156 text files. In alphabetical order, the first 116 are broken. Looking at hexdumps of a few of them now, it seems they all just contains zeros. The rest is fine.

Thanks for your help :slight_smile:

Sounds like a more serious hardware issue, either CPU and/or RAM. (Or even your sdd drive is failing.)

To gauge this, are you able to compare some “original” files (on your source drive) with the exact same files on your backup drive? Can you find any that are different?

rsync would have failed with an error message if the transferred files’ chunks do not pass the integrity checks.

Aw, well, I can’t compare since the source files are gone. :frowning:

I mean any source file, as a test.

Are you saying that you deleted everything?