Difference between revisions of "File recovery"

From ArchWiki
Jump to: navigation, search
m (Failing Drives: style)
(Special Notes: added the "Before you start" section, from my experience this cannot be stressed enough.)
Line 8: Line 8:
=== Special Notes===
=== Special Notes===
==== Before you start ====
This wiki is intended to be used mostly for educational purposes. If you accidentally deleted or otherwise damaged your '''valuable and irreplaceable''' data and have no previous experience with data recovery, turn off your computer immediately (just press the off button or pull the plug, do not use the system shutdown function) and find professional help. It is quite possible that even if you follow all steps described below without fully understanding them, you will probably make things worse.
==== Failing Drives ====
==== Failing Drives ====

Revision as of 00:05, 5 December 2013


Page Overview

This article is meant to capture several file recovery or undelete options for Arch Linux. Please contribute to this page using the general format below and keeping it brief.

Special Notes

Before you start

This wiki is intended to be used mostly for educational purposes. If you accidentally deleted or otherwise damaged your valuable and irreplaceable data and have no previous experience with data recovery, turn off your computer immediately (just press the off button or pull the plug, do not use the system shutdown function) and find professional help. It is quite possible that even if you follow all steps described below without fully understanding them, you will probably make things worse.

Failing Drives

In the area of data recovery, it is best to work on images of disks rather than the physical disks themselves. Generally, a failing drive's condition worsens over time. The goal ought to be to copy as much data as possible as early as possible, and to then abandon the disk. The ddrescue and dd_rescue utilities, unlike dd, will repeatedly try to recover from errors, and will read the drive front to back, then back to front, attempting to salvage data. It keeps a log file so that you can pause and resume recovery without losing your progress.

See Disk Cloning.

The image files created from a utility like ddrescue can then be mounted like a physical device and can be worked on safely. Always make a copy of the original image so that you can revert if things go sour!

A tried and true method of improving failing drive reads is to keep it cold. A bit of time in the freezer is appropriate, but be careful to avoid bringing the drive from cold to warm too quickly, as condensation will form. Keeping the drive in the freezer with cables connected to the recovering PC works great.

Do not attempt a filesystem check on a failing drive, as this will likely make the problem worse. Keep it read-only.

Backup Flash Media/Small Partitions

As an alternative to working with a 'live' partition (mounted or not), it is often preferable to work with an image provided that the filesystem in question is not too large and that you have sufficient free HDD space to accommodate the image file. For example, flash memory devices like, thumb drives, digital cameras, portable music players, cellular phones, etc.

Be sure to read the man pages for the utilities listed below to verify that they are capable of working with an image file.

To make an image, one can use dd as follows:

# dd if=/dev/target_partition of=/home/user/partition.image

Working with Digital Cameras

In order for some of the utils listed in the next section to work with flash media, one needs to have the device in question mounted as a block device (i.e. it is listed under /dev). Digital cameras operating in PTP (Picture Transfer Protocol) mode will not work in this regard. PTP cameras are transparently handled by libgphoto and/or libptp. Transparently as in, they do not get a block device. The alternative to PTP mode is USB Mass Storage (UMS) mode which may or may not be supported by your camera. Some cameras will have a menu item allowing the user to switch between the two modes; refer to your camera's user manual. If your camera does not support UMS mode and therefore cannot be accessed as a block device, your only alternative is to use a flash media reader and physically remove the media from your camera.



Foremost is a console program to recover files based on their headers, footers, and internal data structures. This process is commonly referred to as data carving. Foremost can work on image files, such as those generated by dd, Safeback, Encase, etc, or directly on a drive. The headers and footers can be specified by a configuration file or you can use command line switches to specify built-in file types. These built-in types look at the data structures of a given file format allowing for a more reliable and faster recovery.


foremostAUR is available on the AUR.

External Links



Extundelete is a terminal-based utility that can recover deleted files from ext3 and ext4 partitions. It can recover all the recently deleted files from a partition and/or a specific file(s) given by relative path or inode information. Note that it works only when the partition is unmounted. The recovered files are saved in the current directory under the folder named RECOVERED_FILES/.


extundelete is available in the official repositories.


Derived from the post on Linux Poison.

To recover data from a specific partition, you must know the device name for that partition, which will be in the form '/dev/sdxX', where 'x' is a letter and 'X' is a number. The example used will be /dev/sda4, but your system might use something different depending on your filesystem configuration. If you are unsure, run 'df', which will give you a list of currently mounted partitions.

Once you have determined which partition you want to recover from, you can simply run extundelete as so:

# extundelete /dev/sda4 --restore-file directory/file

Any subdirectories must be specified and the command runs from the highest level of the partition, so if you are recovering a file in /home/user/ (where user/ is your user's home directory), and assuming that your /home directory is on its own partition, you would run

# extundelete /dev/sda4 restore-file user/file

To speed up multi-file recovery, there is a --restore-files option as well.

If you want to recover an entire directory, you can do it simply with

# extundelete /dev/sda4 --restore-directory user/directory

If you are an advanced user and wish to manually recover a block or inode with extundelete, you can use debugfs to find the inode you wish to recover, then run

# extundelete --restore-inode <inode>

<inode> is any valid inode. Additional inodes to recover can be listed in an unspaced, comma-separated fashion.

Finally, if you wish to recover all deleted files from an entire partition, you can do so with

# extundelete /dev/sda4 --restore-all

Testdisk and PhotoRec


TestDisk and Photorec are both open-source data recovery utilities licensed under the terms of the GNU Public License (GPL).

TestDisk is primarily designed to help recover lost partitions and/or make non-booting disks bootable again when these symptoms are caused by faulty software, certain types of viruses or human error (such as accidentally deleting a Partition Table).

Photorec is file data recovery software designed to recover lost files including video, documents and archives from Hard Disks and CDRom and lost pictures (thus, its 'Photo Recovery' name) from digital camera memory. PhotoRec ignores the filesystem and goes after the underlying data, so it will still work even if your media's filesystem has been severely damaged or re-formatted.


testdisk from the official repositories provides both TestDisk and Photorec.

External Links



e2fsck, is the ext2/ext3 filesystem checker included in the base install of Arch. e2fsck relies on a valid superblock. A superblock is a description of the entire filesystem's parameters. Because this data is so important, several copies of the superblock are distributed amongst the partition data. e2fsck can take an alternate superblock argument if the main (first) superblock is damaged (use the -b option).

To determine where the superblocks are, run dumpe2fs -h on the affected, unmounted partition. Superblocks are spaced differently depending on the blocksize specified when the ext2/ext3 filesystem was created.

An alternate method to determine superblocks is to use the -n option with mke2fs. Be sure to use the -n flag, which "causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem. This can be used to determine the location of the backup superblocks for a particular filesystem."


e2fsck and dumpe2fs are included in the base Arch install.

External Links

Working with Raw Disk Images

If you backed up a drive using ddrescue or dd, and you need to mount this image as a physical drive, then look no further!

Mount the Entire Disk

To mount a complete diskimage to the next free loopdevice use the losetup command:

# losetup -f -P /path/to/image
Tip: The -f flag mounts the image to the next available loopdevice
Tip: The -P flag creates additional devices for every partition

Mounting Partitions

In order to be able to mount a partiton of an whole diskimage you need to follow the steps above.

When the whole diskimage is mounted, you can use the normal mount command on the loopdevice:

# mount /dev/loop0p1 /mnt/temp

This command mounts the first partition of the image in loop0 to the folder under /mnt/temp (/mnt/temp must exist!).

Getting Disk Geometry

After mounting the entire disk image as a loopback device, you can inspect it for it's drive layout.

Using QEMU to Repair NTFS

Say you have a disk image that contains one or more NTFS partitions, and you need to run Windows chkdsk to fix the filesystem. QEMU let us you use a raw dd or ddrescue image as a real hard disk inside a virtual machine.

# qemu -hda /path/to/primary.img -hdb /path/to/damagedDisk.img

Text file recovery

It's possible to find deleted plain text on your hard drive with a few commands, you just need to know a (preferably unique) string from the file you are trying to recover.

You need to use first the strings command to dump all the text from your partition :

# strings /dev/hda1 > bigstringsfile

Then grep the strings output for the relevant output

$ grep -i -200 "Unique string in text file" bigstringsfile > grepoutputfile

The -200 option tells grep to report the 200 lines before and after the string you choose.

You can now find in grepoutfile the deleted data.

External links