Nathan Shearer


Data recovery is something that always tends to come up. Having backups is very important, but what if the backups have also failed? Then we are stuck with recovering what we can from the failed media. The first step is almost always: stop using the disk. Do not write anything to it, do not check the disk or filesystem for errors, just stop using it. We do not want to damage the disk further. If the disk works, but then stops working then we might be able to recover some data. If the disk does detect at all in a linux environment, then your next step is to contact a forensic data recovery service provider and have them attempt to perform a lower level physical recovery.

Imaging the Disk(s)

I've used ddrescue many times before, and it is a wonderful tool. It reads every block off of a failing drive, keeping a log of the bad sectors. It can run multiple passes and avoid the bad sectors which is useful if the disk needs to be powercycled. The procedure to create an image of the failing disk is fairly simple:

Connect the disk to a linux computer that can read it. I prefer to to use USB drive docks since I can power cycle the drive without impacting the computer.
Change to a directory with enough space to store the entire disk image. I prefer to have at least double the size of the disk as free space.
  # cd /mnt/recovery
Assuming the disk is /dev/sdb you can now run the first pass of ddrescue:
  # ddrescue /dev/sdb failed-drive.bin failed-drive.log
If/when ddrescue reads a bad sector, sometimes the device will 'disappear'. If that happens, power cycle the drive and run the exact same command again:
  # ddrescue /dev/sdb failed-drive.bin failed-drive.log
Repeate the procedure until ddrescue stops recovering data and says it is "finished"
Optionally, you can now "retrim" the failed blocks. This causes ddrescue to rescan the failed blocks in an attempt to salvage more data:
  # ddrescue --retrim /dev/sdb failed-drive.bin failed-drive.log
Again, rerun the command without --retrim until ddrescue says it is finished:
  # ddrescue /dev/sdb failed-drive.bin failed-drive.log
You can retrim repeatedly if more data is recovered until you are satisfied everything has been salvaged off of the drive

Accessing the Partitions

Now that you have an image of your drive(s), you can now mount the image and copy data from the image. I prefer to mount the image read-only and only modify snapshots of the image if I need to.

Print out the partition table of the image:
  # parted failed-drive.bin unit b print
  Model:  (file)
  Disk /root/failed-drive.bin: 2000398934016B
  Sector size (logical/physical): 512B/512B
  Partition Table: gpt
  Disk Flags:
  Number  Start        End             Size            File system  Name     Flags
   1      1048576B     1025507327B     1024458752B     ext3         primary
   2      1025507328B  6145703935B     5120196608B                  primary
   3      6145703936B  6146752511B     1048576B                     primary
   4      6146752512B  6147801087B     1048576B                     primary
   5      6147801088B  7172259839B     1024458752B                  primary
   6      7172259840B  1992004259839B  1984832000000B               primary
In my example, there are 6 partitions, so we'll setup 6 loop devices:
  # losetup -o 1048576 --sizelimit 1024458752 -f failed-drive.bin
  # losetup -o 1025507328 --sizelimit 5120196608 -f failed-drive.bin
  # losetup -o 6145703936 --sizelimit 1048576 -f failed-drive.bin
  # losetup -o 6146752512 --sizelimit 1048576 -f failed-drive.bin
  # losetup -o 6147801088 --sizelimit 1024458752 -f failed-drive.bin
  # losetup -o 7172259840 --sizelimit 1984832000000 -f failed-drive.bin
Now you can mount the partitions read-only:
  # mkdir /mnt/temp1
  # mount -o ro /dev/loop0 /mnt/temp1
  # mkdir /mnt/temp2
  # mount -o ro /dev/loop1 /mnt/temp2
And copy any/all data that you can to stable storage:
  # mkdir /root/recovered
  # cp -av /mnt/temp1/* /root/recovered
  # cp -av /mnt/temp2/* /root/recovered

% Powered by Modulus %
© 2022 Nathan Shearer