I am helping with an interesting data recovery issue. The laptop was running Debian 11 Linux with LUKS full disk encryption on a Samsung 970 Evo Plus 2TB SSD for quite many months. Suddenly the LUKS password input on boot stopped working.
I connected the disk to another machine and noticed that attempts to mount it caused blk_update_request: critical medium error
in journalctl
and increasing Media and Data Integrity Errors
in SMART attributes.
This looked like a bad sign so I started running ddrescue
to make a full clone of the disk. ddrescue
failed to read only 96 sectors (~50KB) from the entire 2TB SSD. But the interesting part is that problematic sectors appeared exactly in the 16MB area where LUKS2 header is located (and nowhere else). Note that LUKS header on this disk starts at the ~1GB position and the first 2 unencrypted boot partitions are not effected (can can be mounted and data looks good). But this failure in the LUKS header area makes all other data unrecoverable (without LUKS header backup).
It seems suspicious that in a 2TB SSD problematic sectors appeared exactly in the 16MB area where LUKS header is located (and nowhere else). Is this just bad luck or something made it more likely for the failure to appear exactly in the LUKS header? I understand that evil malware could override data in the LUKS header area, but could it cause "Data Integrity Errors"?
Also I am considering any ideas if the failing sectors could be recovered with other methods. So far basically just tried running ddrescue
with some more retries from multiple machines.