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!
You made a backup (using rsync) TO an LUKS encrypted drive - correct?
Meaning:
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.
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.
By data loss, I mean I accidentally deleted the originals. It was a stupid thing, but it happened. 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.
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.
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.)