Difference between revisions of "File recovery"

From ArchWiki
Jump to: navigation, search
(Replaced the placeholder under "Mount the Entire Disk" and "Mounting Partitions" with content. Had to look it up myself, now I want to help others.)
(Text file recovery: merge similar notes)
 
(99 intermediate revisions by 17 users not shown)
Line 1: Line 1:
 
[[Category:File systems]]
 
[[Category:File systems]]
 
[[Category:System recovery]]
 
[[Category:System recovery]]
== Preface/Introduction ==
+
[[ja:ファイルリカバリ]]
 +
[[zh-CN:File recovery]]
 +
{{Related articles start}}
 +
{{Related|Post recovery tasks#Photorec}}
 +
{{Related articles end}}
  
=== Page Overview ===
+
This article lists data recovery and undeletion options for Arch Linux.
  
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==
  
=== Special Notes===
+
=== Before you start ===
  
==== Failing Drives ====
+
This page is mostly intended to be used for educational purposes. If you have 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 and hold the off button or pull the plug; do not use the system shutdown function) and seek professional help. It is quite possible and even probable that, if you follow any of the steps described below without fully understanding them, you will worsen your situation.
  
In the arena 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 (ddrescue in repos, dd_rescue in AUR), 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.
+
=== Failing drives ===
  
See [[Disk Cloning]].
+
In the area of data recovery, it is best to work on images of disks rather than physical disks themselves. Generally, a failing drive's condition worsens over time. The goal ought to be to first rescue as much data as possible as early as possible in the failure of the disk and to then abandon the disk. The {{Pkg|ddrescue}} and {{Pkg|dd_rescue}} utilities, unlike {{ic|dd}}, will repeatedly try to recover from errors and will read the drive front to back, then back to front, attempting to salvage data. They keep log files so that recovery can be paused and resumed without losing 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!
 
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.
+
A tried and true method of improving failing drive reads is to keep the drive 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.
+
Do not attempt a filesystem check on a failing drive, as this will likely make the problem '''worse'''. Mount it read-only.
  
====Backup Flash Media/Small Partitions====
+
=== 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 isn't 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.
+
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. are likely to be small enough to image in many cases.
  
To make an image, one can use dd as follows:
+
Be sure to read the man pages for the utilities listed below to verify that they are capable of working with image files.
 +
 
 +
To make an image, one can use {{ic|dd}} as follows:
 
  # dd if=/dev/target_partition of=/home/user/partition.image
 
  # dd if=/dev/target_partition of=/home/user/partition.image
  
====Working with Digital Cameras====
+
=== 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 don't 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==
+
In order for some of the utilities listed in the next section to work with flash media, the device in question needs to be mounted as a block device (i.e., 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. In this case, "transparently" means that PTP devices do not get block devices. The alternative to PTP mode, USB Mass Storage (UMS) mode, is not supported by all cameras. Some cameras have a menu item that allows switching 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 storage media from your camera.
===Description===
+
 
'''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.  
+
== Foremost==
===Installation===
+
 
'''Foremost''' is available from the [[AUR]] in [https://aur.archlinux.org/packages.php?ID=2014 this page].
+
[http://foremost.sourceforge.net 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 disk 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 command line switches can be used to specify built-in file types. These built-in types look at the data structures of a given file format, allowing for more reliable and faster recovery.
===External Links===
+
 
*Wiki:
+
See [[Foremost]] article.
*Homepage: http://foremost.sourceforge.net
+
 
==Extundelete==
+
== Extundelete ==
===Description===
+
 
'''[http://extundelete.sourceforge.net/ 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 {{ic|RECOVERED_FILES/}}.
+
'''[http://extundelete.sourceforge.net/ Extundelete]''' is a terminal-based utility designed to 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 {{ic|RECOVERED_FILES/}}.
===Installation===
+
 
'''Extundelete''' is available in the [[AUR_User_Guidelines#.5Bcommunity.5D | [community]]] repository; you can simply download it with
+
=== Installation ===
# pacman -S extundelete
+
 
 +
{{Pkg|extundelete}} is available in the [[official repositories]].
 +
 
 +
=== Usage ===
  
===Usage===
 
 
''Derived from the post on [http://linuxpoison.blogspot.com/2010/09/utility-to-recover-deleted-files-from.html Linux Poison].''
 
''Derived from the post on [http://linuxpoison.blogspot.com/2010/09/utility-to-recover-deleted-files-from.html 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 {{ic|/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.
+
To recover data from a specific partition, the device name for the partition, which will be in the format {{ic|/dev/sd''XN''}} (''X'' is a letter and ''N'' is a number.), must be known. The example used here is {{ic|/dev/sda4}}, but your system might use something different (For example, MMC card readers use {{ic|/dev/mmcblkNpN}} as their naming scheme.) depending on your filesystem and device configuration. If you are unsure, run {{ic|df}}, which prints currently mounted partitions.
  
Once you have determined which partition you want to recover from, you can simply run extundelete as so:
+
Once which partition data is to be recovered from has been determined, simply run:
  # extundelete /dev/sda4 --restore-file directory/file
+
  # 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 {{ic|/home/user/}} (where {{ic|user/}} is your user's home directory), and assuming that your {{ic|/home}} directory is on its own partition, you would run
+
Any subdirectories must be specified, and the command runs from the highest level of the partition, so, to recover a file in {{ic|/home/''SomeUserName''/}}, assuming {{ic|/home}} is on its own partition, run:
  # extundelete /dev/sda4 restore-file user/file
+
  # extundelete /dev/sda4 --restore-file ''SomeUserName''/''SomeFile''
To speed up multi-file recovery, there is a --restore-files option as well.
+
To speed up multi-file recovery, extundelete has a {{ic|--restore-files}} option as well.
  
If you want to recover an entire directory, you can do it simply with
+
To recover an entire directory, run:
  # extundelete /dev/sda4 --restore-directory user/directory
+
  # extundelete /dev/sda4 --restore-directory ''SomeUserName''/''SomeDirectory''
  
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
+
For advanced users, to manually recover blocks or inodes with extundelete, debugfs can be used to find the inode to be recovered; then, run:
  # extundelete --restore-inode <inode>
+
  # extundelete --restore-inode ''inode''
<inode> is any valid inode. Additional inodes to recover can be listed in an unspaced, comma-separated fashion.
+
''inode'' stands for 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
+
Finally, to recover all deleted files from an entire partition, run:
 
  # extundelete /dev/sda4 --restore-all
 
  # extundelete /dev/sda4 --restore-all
  
==Photorec==
+
== Testdisk and PhotoRec ==
===Description===
+
'''Photorec''' is a complementary utility to '''TestDisk'''; both open-source data recovery utilities licensed under the terms of the [http://www.gnu.org/licenses/gpl.html GNU Public License] (GPL).  '''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.
+
  
===Installation===
+
TestDisk and Photorec are both open-source data recovery utilities licensed under the terms of the [http://www.gnu.org/licenses/gpl.html GNU Public License] (GPL).
Both '''TestDisk''' and '''Photorec''' are available for Arch i686 and x64_86 in the same package.
+
# pacman -S testdisk
+
  
===External Links===
+
'''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 the accidental deletion of partition tables.
*Wiki (Photorec): http://www.cgsecurity.org/wiki/PhotoRec
+
*Homepage: http://www.cgsecurity.org/
+
  
==Testdisk==
+
'''PhotoRec''' is file recovery software designed to recover lost files including photographs (Hint: '''Photo'''graph'''Rec'''overy), videos, documents, archives from hard disks and CD-ROMs. PhotoRec ignores the filesystem and goes after the underlying data, so it will still work even with a re-formatted or severely damaged filesystems and/or partition tables.
===Description===
+
'''TestDisk''', like '''Photorec''' are both open-source data recovery utilities licensed under the terms of the [http://www.gnu.org/licenses/gpl.html 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).
+
  
===Installation===
+
=== Installation ===
Both '''TestDisk''' and '''Photorec''' are available for Arch i686 and x64_86 in the same package.
+
# pacman -S testdisk
+
  
===External Links===
+
{{Pkg|testdisk}} from the [[official repositories]] provides both TestDisk and PhotoRec.
*Wiki (TestDisk): http://www.cgsecurity.org/wiki/TestDisk
+
*Homepage: http://www.cgsecurity.org/
+
  
==e2fsck==
+
=== Files recovered by photorec ===
===Description===
+
The photorec utility stores recovered files with a random names(for most of the files) under a numbered directories, e.g. {{ic|./recup_dir.1/f872690288.jpg}}, {{ic|./recup_dir.1/f864563104_wmclockmon-0.1.0.tar.gz}}.  
'''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.
+
=== See also ===
  
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."
+
* How to get the original filenames: [http://www.cgsecurity.org/wiki/PhotoRec_FAQ#How_to_get_the_original_filenames_.3F PhotoRec FAQ]
 +
* Wiki (TestDisk): http://www.cgsecurity.org/wiki/TestDisk
 +
* Wiki (Photorec): http://www.cgsecurity.org/wiki/PhotoRec
 +
* Homepage: http://www.cgsecurity.org/
  
===Installation===
+
== e2fsck ==
'''e2fsck''' and '''dumpe2fs''' are included in the base Arch i686 and x64_86 install.
+
  
===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 throughout the partition. With the {{ic|-b}} option, e2fsck can take an alternate superblock argument; this is useful if the main, first superblock is damaged.
*e2fsck man page: http://phpunixman.sourceforge.net/index.php/man/e2fsck/8
+
*dumpe2fs man page: http://phpunixman.sourceforge.net/index.php?parameter=dumpe2fs&mode=man
+
  
==Working with Raw Disk Images==
+
To determine where the superblocks are, run {{ic|dumpe2fs -h}} on the target, unmounted partition. Superblocks are spaced differently depending on the filesystem's blocksize, which is set when the filesystem is created.
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===
+
An alternate method to determine the locations of superblocks is to use the -n option with mke2fs. Be '''sure''' to use the {{ic|-n}} flag, which, according to the {{ic|mke2fs}} manpage, "''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, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again. (With the -n option added, of course!)''".
To mount a complete diskimage to the next free loopdevice use the '''losetup''' command:
+
 
 +
=== Installation ===
 +
 
 +
Both {{ic|e2fsck}} and {{ic|dumpe2fs}} are included in the base Arch install as part of {{pkg|e2fsprogs}}.
 +
 
 +
=== See also ===
 +
 
 +
* e2fsck man page: http://phpunixman.sourceforge.net/index.php/man/e2fsck/8
 +
* dumpe2fs man page: http://phpunixman.sourceforge.net/index.php?parameter=dumpe2fs&mode=man
 +
 
 +
== Working with raw disk images ==
 +
 
 +
{{Merge|QEMU}}
 +
 
 +
If you have backed up a drive using ddrescue or dd and you need to mount this image as a physical drive, see this section.
 +
 
 +
=== Mount the entire disk ===
 +
 
 +
To mount a complete disk image to the next free loop device, use the {{ic|losetup}} command:
 
  # losetup -f -P /path/to/image
 
  # 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 [[File_Recovery#Mount_the_Entire_Disk|the steps above]].
 
  
When the whole diskimage is mounted, you can use the normal '''mount''' command on the loopdevice:
+
{{Tip|
# mount /dev/loop0p1 /mnt/temp
+
* The {{ic|-f}} flag mounts the image to the next available loop device.
This command mounts the first partition of the image in loop0 to the folder under /mnt/temp (/mnt/temp must exist!).
+
* The {{ic|-P}} flag creates additional devices for every partition.
====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's 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 ==
+
See also [[QEMU#With_loop_module_autodetecting_partitions|more information about loop devices]].
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're trying to recover.
+
  
You need to use first the ''strings'' command to dump all the text from your partition :
+
=== Mounting partitions ===
  
  # strings /dev/hda1 > bigstringsfile
+
In order to be able to mount a partiton of a whole disk image, follow [[#Mount the entire disk|the steps above]].
 +
 
 +
Once the whole disk image is mounted, a normal {{ic|mount}} command can be used on the loop device:
 +
  # mount /dev/loop0p1 /mnt/example
 +
This command mounts the first partition of the image in loop0 to the folder to the mountpoint {{ic|/mnt/example}}. Remember that the mountpoint directory must exist!
 +
 
 +
==== Getting disk geometry ====
 +
 
 +
Once the entire disk image has been mounted as a loopback device, its drive layout can be inspected.
 +
 
 +
=== Using QEMU to Repair NTFS ===
 +
 
 +
With a disk image that contains one or more NTFS partitions that need to be {{ic|chkdsk}}ed by Windows since no good NTFS filesystem checker for Linux exists, QEMU can use a raw disk image as a real hard disk inside a virtual machine:
 +
# qemu -hda ''/path/to/primary''.img -hdb ''/path/to/DamagedDisk''.img
 +
Then, assuming Windows is installed on {{ic|''primary''.img}}, it can be used to check partitions on {{ic|''/path/to/DamagedDisk''.img}}.
 +
 
 +
{{Warning|Do not use lower version of Windows to check NTFS partitions create by higher version of it, e.g. Windows XP can do damage to NTFS partitions created by Windows 8 by "fixing" [[wikipedia:NTFS#Metafiles|metadata]] configuration that has support for, not supported entries will be removed or miss-configured.}}
 +
 
 +
== Text file recovery ==
  
Then ''grep'' the strings output for the relevant output
+
It is possible to find deleted plain text files on a hard drive by directly searching on the block device. A preferably unique string from the file you are trying to recover is needed.
  
$ grep -i -200 "Unique string in text file" bigstringsfile > grepoutputfile
+
Use {{ic|grep}} to search for fixed strings ({{ic|-F}}) directly on the partition:
  
The -200 option tells grep to report the 200 lines before and after the string you choose.
+
$ grep -a -C 200 -F 'Unique string in text file' /dev/sd''XN'' > ''OutputFile''
  
You can now find in grepoutfile the deleted data.
+
Hopefully, the content of the deleted file is now in ''OutputFile'', which can be extracted from the surrounding context manually.
  
 +
{{Note|The {{ic|-C 200}} option tells grep to print 200 lines of context from before and after each match of the string. Alternatives are the {{ic|-A}} and {{ic|-B}} flags, which print context only from after and before each match, respectively. You may need to adjust the number of lines if the file you are looking for is very long.}}
  
 +
== See also ==
  
==External links==
+
* [https://help.ubuntu.com/community/DataRecovery Data Recovery] on the Ubuntu wiki
*[https://help.ubuntu.com/community/DataRecovery Data Recovery] on the Ubuntu wiki
+

Latest revision as of 08:53, 19 May 2016

This article lists data recovery and undeletion options for Arch Linux.

Special notes

Before you start

This page is mostly intended to be used for educational purposes. If you have 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 and hold the off button or pull the plug; do not use the system shutdown function) and seek professional help. It is quite possible and even probable that, if you follow any of the steps described below without fully understanding them, you will worsen your situation.

Failing drives

In the area of data recovery, it is best to work on images of disks rather than physical disks themselves. Generally, a failing drive's condition worsens over time. The goal ought to be to first rescue as much data as possible as early as possible in the failure of the disk 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. They keep log files so that recovery can be paused and resumed without losing 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 the drive 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. Mount 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. are likely to be small enough to image in many cases.

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

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 utilities listed in the next section to work with flash media, the device in question needs to be mounted as a block device (i.e., 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. In this case, "transparently" means that PTP devices do not get block devices. The alternative to PTP mode, USB Mass Storage (UMS) mode, is not supported by all cameras. Some cameras have a menu item that allows switching 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 storage media from your camera.

Foremost

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 disk 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 command line switches can be used to specify built-in file types. These built-in types look at the data structures of a given file format, allowing for more reliable and faster recovery.

See Foremost article.

Extundelete

Extundelete is a terminal-based utility designed to 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/.

Installation

extundelete is available in the official repositories.

Usage

Derived from the post on Linux Poison.

To recover data from a specific partition, the device name for the partition, which will be in the format /dev/sdXN (X is a letter and N is a number.), must be known. The example used here is /dev/sda4, but your system might use something different (For example, MMC card readers use /dev/mmcblkNpN as their naming scheme.) depending on your filesystem and device configuration. If you are unsure, run df, which prints currently mounted partitions.

Once which partition data is to be recovered from has been determined, simply run:

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

Any subdirectories must be specified, and the command runs from the highest level of the partition, so, to recover a file in /home/SomeUserName/, assuming /home is on its own partition, run:

# extundelete /dev/sda4 --restore-file SomeUserName/SomeFile

To speed up multi-file recovery, extundelete has a --restore-files option as well.

To recover an entire directory, run:

# extundelete /dev/sda4 --restore-directory SomeUserName/SomeDirectory

For advanced users, to manually recover blocks or inodes with extundelete, debugfs can be used to find the inode to be recovered; then, run:

# extundelete --restore-inode inode

inode stands for any valid inode. Additional inodes to recover can be listed in an unspaced, comma-separated fashion.

Finally, to recover all deleted files from an entire partition, run:

# 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 the accidental deletion of partition tables.

PhotoRec is file recovery software designed to recover lost files including photographs (Hint: PhotographRecovery), videos, documents, archives from hard disks and CD-ROMs. PhotoRec ignores the filesystem and goes after the underlying data, so it will still work even with a re-formatted or severely damaged filesystems and/or partition tables.

Installation

testdisk from the official repositories provides both TestDisk and PhotoRec.

Files recovered by photorec

The photorec utility stores recovered files with a random names(for most of the files) under a numbered directories, e.g. ./recup_dir.1/f872690288.jpg, ./recup_dir.1/f864563104_wmclockmon-0.1.0.tar.gz.

See also

e2fsck

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 throughout the partition. With the -b option, e2fsck can take an alternate superblock argument; this is useful if the main, first superblock is damaged.

To determine where the superblocks are, run dumpe2fs -h on the target, unmounted partition. Superblocks are spaced differently depending on the filesystem's blocksize, which is set when the filesystem is created.

An alternate method to determine the locations of superblocks is to use the -n option with mke2fs. Be sure to use the -n flag, which, according to the mke2fs manpage, "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, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again. (With the -n option added, of course!)".

Installation

Both e2fsck and dumpe2fs are included in the base Arch install as part of e2fsprogs.

See also

Working with raw disk images

Merge-arrows-2.pngThis article or section is a candidate for merging with QEMU.Merge-arrows-2.png

Notes: please use the second argument of the template to provide more detailed indications. (Discuss in Talk:File recovery#)

If you have backed up a drive using ddrescue or dd and you need to mount this image as a physical drive, see this section.

Mount the entire disk

To mount a complete disk image to the next free loop device, use the losetup command:

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

See also more information about loop devices.

Mounting partitions

In order to be able to mount a partiton of a whole disk image, follow the steps above.

Once the whole disk image is mounted, a normal mount command can be used on the loop device:

# mount /dev/loop0p1 /mnt/example

This command mounts the first partition of the image in loop0 to the folder to the mountpoint /mnt/example. Remember that the mountpoint directory must exist!

Getting disk geometry

Once the entire disk image has been mounted as a loopback device, its drive layout can be inspected.

Using QEMU to Repair NTFS

With a disk image that contains one or more NTFS partitions that need to be chkdsked by Windows since no good NTFS filesystem checker for Linux exists, QEMU can use a raw disk image as a real hard disk inside a virtual machine:

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

Then, assuming Windows is installed on primary.img, it can be used to check partitions on /path/to/DamagedDisk.img.

Warning: Do not use lower version of Windows to check NTFS partitions create by higher version of it, e.g. Windows XP can do damage to NTFS partitions created by Windows 8 by "fixing" metadata configuration that has support for, not supported entries will be removed or miss-configured.

Text file recovery

It is possible to find deleted plain text files on a hard drive by directly searching on the block device. A preferably unique string from the file you are trying to recover is needed.

Use grep to search for fixed strings (-F) directly on the partition:

$ grep -a -C 200 -F 'Unique string in text file' /dev/sdXN > OutputFile

Hopefully, the content of the deleted file is now in OutputFile, which can be extracted from the surrounding context manually.

Note: The -C 200 option tells grep to print 200 lines of context from before and after each match of the string. Alternatives are the -A and -B flags, which print context only from after and before each match, respectively. You may need to adjust the number of lines if the file you are looking for is very long.

See also