safecopy: recover data from corrupt media

cool_penguin_smallHard disk or CD with important information gone bad? You might still be able to recover readable data using the low-level rescue tool safecopy. It’s a utility similar to GNU ddrescue.

safecopy does not fail where other tools (like cat or cp) fail on encountering an I/O error. It uses low level IO to read media in raw mode as well as direct hardware access with O_DIRECT instead of making calls through the virtual filesystem. In addition it issues device resets and other helpful low level operations.

Users can force continue a previous safecopy run at arbitrary position. It can keep trying to open source files even when they went away. This allows copying from devices that vanish temporarily in case of errors, like USB drives that renumerate in case of device resets.

From the developer notes: internally safecopy does this by identifying and skipping problematic or damaged areas, and continuing reading afterwards. The corresponding area in the destination file is either skipped (on initial creation that means padded with zeros) or deliberately filled with a recognizable pattern to later find affected files on a corrupted device. safecopy uses an incremental algorithm to identify the exact beginning and end of bad areas, allowing the user to trade minimum accesses to bad areas for thorough data resurrection. Multiple passes over the same file are possible, to first retrieve as much data from a device as possible with minimum harm, and then trying to retrieve some of the remaining data with increasingly aggressive read attempts.

safecopy can generate data to simulate a corrupt media. This data can be used to benchmark safecopy against similar data recovery tools.

Installation

To install safecopy on Ubuntu:

$ sudo apt-get install safecopy

Usage

A few common use cases:

  • To view the options safecopy provides, run:
    $ safecopy --help
  • Resurrect a file from a mounted but damaged media, that cp failed on:
    $ safecopy /path/to/problemfile ~/saved-file
  • Create a filesystem image of a damaged disk/cdrom:
    $ safecopy /dev/device ~/diskimage
  • Interrupt and later resume a data rescue operation:
    $ safecopy source dest
    <CTRL+C> (safecopy aborts)
    $ safecopy source dest -I /dev/null
  • Find the corrupted files on a partially successful rescued file system:
    $ safecopy /dev/filesystem image -M CoRrUpTeD
    $ fsck image
    $ mount -o loop image /mnt/mountpoint
    $ grep -R /mnt/mountpoint "CoRrUpTeD"
  • Create an image of a device that starts at X and is Y in size:
    $ safecopy /dev/filesystem -b  -s <X/bsize> -l <Y/bsize>

Webpage: safecopy

Jaypack: recover images from corrupt filesystem

image_editor_compLosing your images can be costly. You’ll definitely miss those precious moments from your kid’s childhood lost due to a disk or filesystem failure. Here’s the good news – if the disk is still readable there’s a chance that you can recover the images, thanks to Jaypack. It is a small open source tool that scans your disk to recover the files.

Jaypack works on a simple algorithm. It bypasses the filesystem and scans the disk for the image signature. To be more accurate, it checks for the characteristical SOI signature: FF D8 FF, followed by a byte determining the type of the image (at the time of writing only for JPEG/JFIF, SPIFF and Exif images can be recovered) and then keeps track of these, as well as EOI signatures (FF D9).

The tool is still under development and has its limitations – it uses a linear algorithm, has a limit on the maximum size of a file (by default set to 10MB, but configurable) and a number of skip bytes, during which EOI byte sequences won’t be honored. It also tends to sacrifice smaller images for bigger ones.

Installation

You need to compile the tool to use it. Download the source archive, extract it, cd into the source code directory and run:

$ make

It will generate 3 binaries: jaypack, jaypack-server, jaypack-client.

Usage

1. The simplest form of usage is:

$ sudo dd if=/dev/sdXn bs=8192 | ./jaypack max_size skip
where
sdXn: device node (e.g. sda, sdb2)
max_size: maximum size (in bytes) of the file jaypack will consider
skip: number of bytes to skip at the beginning (default 0, ~16000 recommende

The output will be a sequence of lines in the following format:

<jpgtype> <offset> <size>

You can then use dd to recover the files.

2. Client server way

jaypack-client will take the output of jaypack from stdin, extract data at those offsets and then output this in an idiotical binary format to stdout. jaypack-server will be able to take that binary format from stdin and then save .jpg files in a folder of your choosing. Example:

$ sudo dd if=<device> skip=<offset> bs=<bs> | 
  ./jaypack - 16384 |
  sudo ./jaypack-client <device> <offset * bs> <extrasize> |
  ./jaypack-server <output-dir>/

3. Over the network

You can start the client on a computer where a live CD is booted, for instance, and pipe the recovered .jpgs over the network to another computer where you can safely stash them.

Run the following command on the server:

$ nc -l -p <server_port> | ./jaypack-server recovered-jpegs/

Run the following on the client (from which to recover images):

$ sudo dd if=/dev/sda1 skip=131072 bs=8192 |
  ./jaypack - 16384 |
  sudo ./jaypack-client /dev/sda1 1073741824 64 |
  nc <server_ip> <server_port>

Webpage: Jaypack

Corrupt superblock? Recover ext2/ext3/ext4 filesystem data

diskMy build VM got corrupt today and I was on the verge of losing my temporary changes scattered across 4 different code branches. I googled a while for a solution and and I found the following links very useful:

Additionally, using TestDisk I was able to copy all my modified code even before I tried fixing the disk. TestDisk came to my rescue once before as well when my 1 TB NTFS formatted externally powered disk was not getting detected anywhere.

Another interesting article on how to handle bad blocks on hard disk.