Use of ddrescue – saving a failing EXT4 drive -fsck results in all data in to lost+found

Posted on

Problem :

I’ve tried….I’m now out of my depth! Any help is very appreciated

I’m currently trying to rescue some data from old disk drives, from the days before I religiously backed everything up. Unfortunately I have a 1TB drive that has a large amount of files on that I would ideally not like to loose forever that isn’t playing ball! I was copying files from this drive just using file manager (Nautilus – Fedora) then started having a lot of copy issues. On next bootup I couldn’t mount the drive. FSCK –Y appeared to fix this drive enough that it could be mounted again, though now with very limited/slow access to the drive. In comes ddrescue.

After weeks of ddrescue doing it’s thing I thought I was getting somewhere, 99.5% recovered sounds like a good stat to me!

sudo ddrescue /dev/sdb1 /dev/sda1 ~/log_file --force --verbose
GNU ddrescue 1.25
About to copy 1000 GBytes from '/dev/sdb1' to '/dev/sda1'
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors       Initial skip size: 19584 sectors
Sector size: 512 Bytes
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 995408 MB, tried: 4794 MB, bad-sector: 4794 MB, bad areas: 104367
Current status
     ipos:        0 B, non-trimmed:        0 B,  current rate:       0 B/s
     opos:        0 B, non-scraped:        0 B,  average rate:       0 B/s
non-tried:        0 B,  bad-sector:    4794 MB,    error rate:       0 B/s
  rescued:  995408 MB,   bad areas:   104367,        run time:          0s
pct rescued:   99.52%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Finished

However, I then used fsck -y to try and fix the file system to allow me to mount this drive (sda1). After a while and lots of screen activity I was then able to mount the drive but everything has been put in to lost+found. I notice that there are working files in there (.jpg images that I can load and .mp3s that play). With no file structure and file names however this is far from ideal!

Running e2fsck on the recovery drive shows the following.

e2fsck -f -v /dev/sda1
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
      648943 inodes used (1.06%, out of 61054976)
        3238 non-contiguous files (0.5%)
         122 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 1/0/0
             Extent depth histogram: 648201/728
   222734516 blocks used (91.21%, out of 244190208)
           0 bad blocks
          18 large files

      618856 regular files
       30073 directories
           0 character device files
           0 block device files
           0 fifos
           1 link
           5 symbolic links (5 fast symbolic links)
           0 sockets
------------
      648935 files

Using file explorer on the mounted original failed drive (SDB1) I can still see the top level file structure (4 folders), though these all appear empty, this gave me some hope that some remnants of the file system must remain? After rebooting the machine this fedora is again struggling to mount the drive.

Is there something I’ve missed?

Included here the ddrescueview output, not sure if this helps identify the failure type?
ddrescueview image

Solution :

After weeks of ddrescue doing it’s thing I thought I was getting somewhere, 99.5% recovered
sounds like a good stat to me!

Although your ddrescue shows a lot of bad areas but no single read error – what is something I can’t understand right now – you did the wrong thing by applying e2fsck to the recovery drive.

This prevents you to continue your rescue process using the old logfile.

Instead you should have copied your rescue drive to another drive called play drive after rescuing the faulty? source to the rescue drive.
This second duplicate should be pretty fast with no physical errors on your rescue drive.

If you now want to go beyond the 99,52% you are forced to restart the recovery as a result of your e2fsck repair effort putting stress on a possible already broken source drive.

The tool you are using is called ddrescue not ddrscue. Please try to correct this error to enable others to find your issue.

Leave a Reply

Your email address will not be published. Required fields are marked *