Data Recovery Using dd_rescue
_________________________________________
_Data recovery using dd_rescue_
Purpose
So a few weeks ago I had my /home partition [on reiserfs] refusing to mount at boot due
to filesystem inconsistencies. While I have managed to solve that problem without being
required to rescue my data, it struck me that there should be readily available information
regarding this topic. And so it got to me to write this short tutorial.
Scenario
You have a corrupted partition. It doesn not matter that the respective disk cannot be saved,
as long as the data can be retrieved, or at least as much as possible. No incremental backups
or anything of the sort exist. A raw read is required.
For the purposes of this tutorial I have recovered the /boot partition for one of my boxes.
While it was not corrupted in any way I have treated the recovery process as if it were.
Tools
Computer [sic]
Helix v1.6 LiveCD - it comes with dd_rescue preinstalled as it is a Linux LiveCD
distribution aimed at forensics and data recovery; however any would work - possibly even
the OS that is already installed if there are partitions working still. To note, Helix
does not touch anything on the guest computer. To get just the program: dd_rescue URL
USB Memory Stick - used for data transfer; another drive or partition could work just as well.
Process for Recovery
1. Pop in Helix on boot time on the computer that has the corrupted drive. You can plug in the USB
stick at the same time as it will be detected automatically and an entry will be made in /etc/fstab
2. Just hit Enter at the main screen for Helix and let it boot up and do its thing. Eventually you
will arrive in the Helix main graphical window [on XFCE].
3. From the XFCE menu [bottom left by default] go and select one of the terminals that you are most
comfortable with and open it.
4. Do the following:
Code:
$ su
# cat /etc/fstab
# mount -t vfat /dev/sda1 /mnt/sda1
# dd_rescue /dev/hda1 /mnt/sda1/hda1.rescue
In a nutshell, you are switching to root [no password], identifying exactly how Helix detected
the USB stick and mounting this under /mnt/sda1. Then the basic dd_rescue syntax will copy the content
of /dev/hda1 to the file hda1.rescue on the USB stick. Of course you should replace hda1 with the
partition name you want to recover and sda1 with the name of the USB stick.
It pays to notice that if you simply refer to the USB stick [say, /mnt/sda1/] then the filesystem will
be transferred on the root of the stick. What this will result in is converting the file system to
whatever the rcovered partition was originally [in my case, ext2]. To get back to FAT you will need to
reformat the drive in a Windows machine, and this would be a bit of a hassle for some [of course, if
you only need the USB stick across Linux machines that would not matter]. That is why I recommend
copying to a file which can then be mounted:
Code:
mount -t ext2 -o loop /dev/sda1/hda1.rescue /mnt/rescue/
on a working machine. You can now navigate the files without any problems whatsoever. Please note
that ext2 is the type of filesystem that my partition had; sometimes you will need to do some trial and
error until you get the write one [-t auto might help if Linux manages to read the superblock]
Additional Notes
1. Helix will mark your USB stick as read-only in /etc/fstab. You could either edit that line using vi or
manually mount the drive as shown above.
2. dd_rescue does not care what kind of partition you're recovering; it pays to know what it is, however,
for when you are mounting it.
3. Complete options are available from
or
Generally the simple method should work [faster or slower depending on how corrupt the partition is]
but in case you only want to copy bits or parts of the drive you can use -s to set the start position
in the input file [the drive to be recovered] and could combine this with -r which reads in reverse.
4. One switch which could be useful in the case of many errors on the drive would be -l
which will log things. This could be useful in generating a file containing the list of badblocks
[required by some fsck tools like the ones for reiserfs]
Caveats
The partition I have recovered was in good condition. That is to say, no errors where encountered on read.
The point where this might make a difference is when it comes to mounting the saved file as it could have
numerous holes in it. However additional damage to the data with more possible loss would not incur. I
believe that dd_rescue should be a first step once a disk seems to show signs of damage.
_________________________________________
