0

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

Improve this question
3
  • Missing 0.5% may be very important. Read the last part of this answer.
    – Kamil Maciorowski
    Commented May 16, 2020 at 10:47
  • thanks, is it possible that the initial fsck on the disk has already nuked the file system, are there other tools I should be using to try repairing this?
    – Ian Cooper
    Commented May 16, 2020 at 16:29
  • Kamil, your answer (linked) is a really nice explanation of the filesystem structure, thanks for putting it so clearly. I understand that this could have happened but struggling to see why the top level wouldn't be recovered (since I can still see this in the original drive?). Additionally, is there any other option other than running fsck on a copy of the ddrescue data/trying to get ddrescue to read more of the drive before doing another fsck in the hope that some more of the file system 'contents page' is recovered? thanks again
    – Ian Cooper
    Commented May 16, 2020 at 16:49

1 Answer 1

Reset to default
0

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.

Improve this answer
6
  • fixed (the spelling!), thanks for the spot. Agreed, I think I was just too keen to get the process moving along and didn't think clearly on that one. Fortunately the drive is at least still responding so I have put another blank drive in to the machine and started a second rescue attempt to that. Obviously aware this is far from ideal.... Would your suggestion be that I have to keep trying DDRESCUE to attempt to get more data in order to recover the file structure? Is there something other than e2fsck I should be running on the 'play' drive, -y flag was perhaps a little....aggressive.
    – Ian Cooper
    Commented May 17, 2020 at 9:32
  • Apply smartmontools with smarctl -a /dev/sda1 > /home/yourprofile/smartlog.txt and look at the file. Use Testdisk to see if you can browse content. If you did not interrupt ddrescue give it a retry using your old logfile to work on the bad areas. If it does not progress anymore your 99,52% are probable all you could get.
    – r2d3
    Commented May 17, 2020 at 10:15
  • which file is this looking at specifically? Is this the ddrescue log file or some log from the fsck command I used to ruin the ddrescue data? i retried a few times and it immediately claimed finished, I might have to play with the retry settings this time round (fingers crossed). thanks for the help!
    – Ian Cooper
    Commented May 17, 2020 at 10:33
  • It is the log file that is used by ddrescue to keep track of the areas and sectors already searched. It enables ddrescue to stop and restart as all administrative recovery information is contained in here - except for the rescued data which reside on the target drive/file.
    – r2d3
    Commented May 17, 2020 at 12:56
  • yeah, i've been using ddrescueview so far to view that, will try with smartmontools Am I screwed looking at the data though/re-running ddrescue since fsck has rearrange the disk completely in to lost and found. Thanks r2d3!
    – Ian Cooper
    Commented May 17, 2020 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .