Ubuntu – How to recover data from a clicking/dying external drive

Make an image of the offending device with ddrescue - You will require enough storage space to hold the entire drive regardless of the amount of data you have (or had) stored on it in this case it appears you'll need 16GB to store a clone of /dev/sdb.

ddrescue is the program that will be doing the work and if it's not installed we need to install it with sudo apt-get install gddrescue (not a typo, the g is short for GNU)

Open a terminal with CtrlAltT and change to the directory that you will be storing the image file in and issue the command sudo ddrescue -d /dev/sdb sdb.img sdb.logfile

the -d directs direct access to the drive (ignoring caching) /dev/sdb is the device we are using for input sdb.img is the file we are using for output sdb.logfile is keeping track of where we are and what our results are.

If for any reason the process is stopped before completion, the logfile allows picking up where we left off.

imaging will begin and you will see something like this:

Rescued indicates the amount of data successfully read, errsize indicates the size of unreadable data. As the process continues we hope to see the former increase and the latter approach zero. ddrescue uses a process called data carving as I recall in which failed blocks are halved and re-tried.

ddrescue is a very powerful tool and you can learn a great deal about it in the manual. Pay close attention to Chapter 3!! choosing the wrong file or device for output will definitely ruin your day.

After we have the resulting image we can run tests and recovery procedures on it without any further stress to the failing or failed device.

Eventually ddrescue will output "Finished" to the terminal screen. If the errsize is high and you feel like you might want to try to recover a little more you can re-run the command and apply switches to re-try failed blocks and even read in reverse (likely not helpful on a solid state device) by: sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfile or any other combination of switches you think might be helpful in the aforementioned manual. Once you've finished attempting to recover all the data, it's time to see what we have.

Issue the command fdisk -l sdb.img or whatever you named your image. With any luck you'll get output similar to this indicating that the partition table is intact.

Disk sdb.img: 4013 MB, 4013948928 bytes
1 heads, 24 sectors/track, 326656 cylinders, total 7839744 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000174fe

  Device Boot      Start         End      Blocks   Id  System
sdb.img1   *        2048     7839743     3918848    b  W95 FAT32

Note the "Start" number This means the file system starts on sector 2048.

Armed with this information and some basic math skills or a calculator we can arrive at the offset that we need to try our processes on. 2048 sectors X 512 bytes per = 1048576

since we created this image due to failure we will first attempt to repair the filesystem

issue the command sudo losetup --offset 1048576 /dev/loop2 sdb.img to setup the image on a loop device.

then issue the command sudo fsck /dev/loop2

After we've repaired the system to the best of our ability we will create a mount point with sudo mkdir /mnt/loop and mount the previously setup loop device with sudo mount /dev/loop2 /mnt/loop

Now hopefully we have some data we can copy over to another drive. let's look:

ls /mnt/loop
autorun.inf  casper-rw  ldlinux.sys  pool                smart-fail.txt
boot         dists      md5sum.txt   preseed             syslinux
casper       install    pics         README.diskdefines  wubi.exe

It looks like I have some. Hopefully you do too! after finishing copying my files I unmount the loop device with sudo umount /dev/loop2

If this approach has been less than successful I can also try testdisk with the command `sudo testdisk sdb.img (or whatever you named your image file). Press enter to select the image, then choose the partition type if a type is detected it will give you a hint on how to proceed. Note that this is usually Intel on flash drives.

You can choose Analyze to search for lost partitions or go directly to Advanced for the file system tools to select an already known or recovered partition. After selection of the partition you will be shown a file listing with instructions on how to select files for copying and etc. This part is fairly self-explanatory and is likely covered elsewhere so I'll stop here with the promise that if anything is unclear you can drop me a comment and I'll get back to you.

I am assuming that you used the "Encrypt the new Ubuntu installation" or its manual equivalent; that is, your hard disk is encrypted by LUKS and in the encrypted container you have an LVM volume group.

Before starting, make sure that you have cryptsetup and lvm2 installed; if not, install them:

sudo apt-get install cryptsetup-bin lvm2

1. Take the drive out and put it into a USB enclosure.

2. Connect it to a working computer running Ubuntu or any other Debian derivative; you can even use a live DVD or USB flash drive for this. Say that the disk is seen by the system as /dev/sdb.

3. Find out which partition on the disk is the LUKS container:

   for p in /dev/sdb*; do
     sudo cryptsetup isLuks $p && echo $p is a LUKS container
   done
   

4. For example, suppose that you found out that /dev/sdb2 is a LUKS container. Open it:

   sudo crypsetup luksOpen /dev/sdb2 old-hard-disk
   

5. LVM should automatically detect the logical volumes; see if it did so with

   sudo lvs -o full_name,size,seg_pe_ranges
   

   If not, you may have to trigger LVM recognition with sudo vgchange -aay.

6. Now you have the logical volumes in /dev/mapper. Mount them onto some directories.