Subscribe to the feed
Linux 

In How to prevent and recover from accidental file deletion in Linux, we addressed local and remote backups, how to reduce your file recovery drama with smart management of file deletion commands, and general best practices for responding to file recovery emergencies. Unfortunately, accidents happen, and hardware fails. One tool to turn to when it’s time to recover lost files or filesystems is TestDisk.

Note: If you don’t have a mandatory backup plan, implement one now. The first time you don’t have to resort to TestDisk because you have a backup image, the planning and preparation pay for themselves in both time and peace of mind.

TestDisk attempts to recover lost partition data and any lost files within the bounds of the recovered partition. This tool may be able to recover your data on its own, or you might use it in conjunction with Scalpel—a file extraction tool—by first using TestDisk to obtain a disk image, and then scanning the image for file types with Scalpel. You can find more on using Scalpel in an upcoming article.

TestDisk is less focused and more flexible than Scalpel, so how you use this tool depends on the situation.  TestDisk is an interactive application, so begin by pointing it to the victim device or image. For example:

$ sudo ./testdisk_static /dev/sdx 
	
Disk /dev/sdx - 1939 MB / 1850 MiB - General UDisk

Please select the partition table type, press Enter when done.
 [Intel  ] Intel/PC partition
>[EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)
 [Humax  ] Humax partition table
 [Mac    ] Apple partition map
 [None   ] Non partitioned media
 [Sun    ] Sun Solaris partition
 [XBox   ] XBox partition
 [Return ] Return to disk selection

TestDisk attempts to detect the correct partition map, but if you know better, you can override its guess with a specific location. Once you choose a partition scheme, TestDisk offers its main menu. Here you can analyze files, recover them, or modify the disk’s geometry and options. The typical workflow is to analyze and then recover.

Running TestDisk on an example lab thumb drive returns this analysis: 

TestDisk 7.0, Data Recovery Utility, April 2015

Disk /dev/sdb - 1939 MB / 1850 MiB - CHS 1018 60 62
Partition    Start       End    Size in sectors
>D MS Data        2046    3788757    3786712 [wreck]
 D MS Data        75744     84543      8800 [NONAME]

In this case, the lost partition was named wreck, and TestDisk successfully discovered its boundaries. If the only lost data you are recovering from is the loss of a partition map, then at this point, you can use this data to recreate that map using GNU Parted

Successful analysis unlocks several new options in the Advanced menu. Armed with the partition’s boundaries, you can dump this partition's data to an image file:

Partition                  Start        End    Size in sectors
> 1 P Unknown                     2048    3788766    3786719
	 
	 
[  Type  ] >[Image Creation]  [  Quit  ]

You can then use Scalpel on the image to recover individual files.

Alternatively, you may know the partition and filesystem type (Type), in which case you can dictate how TestDisk treats the data. Doing this can help TestDisk locate a backup Superblock, enabling you to use mkfs to recover the data like so:

Disk /dev/sdb - 1939 MB / 1850 MiB - CHS 1018 60 62
Partition                  Start        End    Size in sectors
MS Data                     2048    3788759    3786712 [wreck]
superblock 32768, blocksize=4096 [wreck]
superblock 98304, blocksize=4096 [wreck]
superblock 163840, blocksize=4096 [wreck]
superblock 229376, blocksize=4096 [wreck]
superblock 294912, blocksize=4096 [wreck]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

Or, you can use TestDisk to detect files with the List menu option:

Partition                  Start        End    Size in sectors
> 1 P EFI System                  2048    3788766    3786719

[Type]  [Superblock] >[  List  ]  [Image Creation]  [  Quit  ]

Using TestDisk is definitely a journey. As long as you previously made a backup of the drive you are attempting to rescue, this tool is generally safe to experiment with when trouble happens. If you’re only experimenting, though, it’s safest to do so on a separate, test machine.

And please do experiment. The experience you’ll gain from practicing is invaluable.


About the author

Seth Kenlon is a Linux geek, open source enthusiast, free culture advocate, and tabletop gamer. Between gigs in the film industry and the tech industry (not necessarily exclusive of one another), he likes to design games and hack on code (also not necessarily exclusive of one another).

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech