NTFS rescue and file recovery

I recently recovered files from a damaged disk several years later using `ddrescue`, `ddrutility` and `scrounge-ntfs`, all of which are impressive tools which deserve wider recognition.

#The context

A relative recently experienced data corruption back in 2023 and mistakenly removed the in-program backup. I wasn't available to quickly do recovery before the storage blocks would be reused. I started investigating earlier this year but couldn't do much as the corruption was not local as I had expected but truncated files.

Turns out there was a backup from 2021 but the disk seemed dead and made Windows crash.

#TL;DR:

  1. ddru_ntfsbitmap to focus on relevant zones
  2. ddrescue
  3. ddrescueview for progress tracking
  4. scrounge_ntfs to extract files without the directory structure

#ddrescue

First step as always is to plug the disk, not mount it, and run ddrescue. There was an issue however: the disk is larger than the free space on my machine.

#ddrutility's ddru_ntfsbitmap

Quoting the manpage: 

Reads the bitmap file from a NTFS partition and creates a domain logfile
to use with GNU ddrescue so that only the used portion of the partition is
recovered.

This means it will read a few dozen megabytes and create a file to instruct ddrescue to skip the unused space. I'm not entirely sure if that space would have been all zeroes anyway and therefore efficiently stored thanks to ddrescue's --sparse option but I couldn't really try.

Usage is simple: 

ddru_ntfsbitmap -V /dev/sdb2 sdb2_ddru_ntfsbitmap.log

I had no read error during the process and the result was to skip half of the disk which did the trick (well, I freed space while ddrescue was running but that worked out fine).

#ddrescue with ddru_ntfsbitmap's output

Plugging it in ddrescue is trivial: 

ddrescue -M -m sdb2_ddru_ntfsbitmap.log /dev/sda2 sdb2_ddrescue sdb2_ddrescue_logfile

I should have used --sparse but was focused on the bitmap aspect and hadn't used ddrescue in a while. It wouldn't have changed much this time anyway.

And then, wait. Reading was slow and speed varied a lot. This made me all the more happy that half of the disk could be skipped.

#ddrescueview

While running, ddrescue gives a pretty nice status in the terminal but it does't tell if you corruption is local or spread all around, which can give an indication on how damaged the file system is.

ddrescueview is a GUI that reads ddrescue's log file and shows sectors as not read, read, to be retried, ... If you liked the Windows defragmenter, you'll love this too. Except the view gives you information.

#scrounge-ntfs

After 20 hours or so (IIRC), ddrescue finished. I tried a few times more, including with a refrigerated disk which can help sometimes, but that didn't get me any further. Actually, at some point my USB port gave up; I thought that was the disk during several days but a USB stick didn't work either. Anyway, I couldn't get a single byte more out of the disk.

I could mount the filesystem, list the root directory and nothing else. I couldn't descend in directories, or at least, not in the ones that mattered for me. The directory structure was unusable.

That's where scrounge-ntfs shines: it can extract files along with their filenames, without consideration for the directories. This means that everything will be stored in a single directory and files with the same names get a .<number> appended.

At that point my issue was the opposite: I had obtained too much data and needed to do some filtering. After a few tries, I found a file that worked and let me recover data at least until end of 2022 which is better than we could have hoped!

#Updates

#Reports

#Notes