Have you ever deleted a file and instantly regretted it? You need it back, and fast! But what if the file is so new, it hasn’t yet been backed up? Fortunately, there’s something you can do about it.
rm: Short for Remorse?
It’s all too easy to use the rm command and find yourself staring at a terminal window with a deepening sense of regret. One small mistake with wildcards, and you can wipe out a lot more than you intended to.
The default Linux file system, ext4 uses inodes to hold data about each file and an inode table to keep track of the inodes. The inode contains metadata about the file, such as its name, who owns it, what the permissions are, and so on.
It also contains entry points to hard links that point to the file. Each file has at least one hard link. Each time you create a new hard link, the hard link count increases by one. Each time you remove a hard link, the hard link count in the inode is reduced by one.
When you delete a file the inode has marked as unused (and ready for reuse), the last hard link is removed. When this happens, the file won’t appear in directory listings, and it cannot be used or accessed.
However, the data that made up the contents of the file is still present on the hard drive. If you could patch the inode so it contained the correct information, though, the file would be restored. Of course, this would only work if the data that makes up the file on the hard drive remains intact and isn’t overwritten.
Alternatively, you could create a new inode, copy the surviving data from the old inode, and then replace the missing bits.
Those are nontrivial activities. Usually, when you delete a file by mistake, it’s at the worst possible moment. It’s always when you need that file, and you need it now. You don’t have time to get down and dirty with sector editors and other utilities. Plus, if it’s a file you just created, it likely hasn’t yet been backed up, so those won’t help you, either.
This where testdisk comes in. It’s easy to use and doesn’t require detailed, low-level knowledge of the filesystem. Let’s take a look at how to use it!
RELATED: Everything You Ever Wanted to Know About inodes on Linux
Installing testdisk
To install testdisk on Ubuntu, use this command:
sudo apt-get install testdisk
On Fedora, you need to type:
sudo dnf install testdisk
On Manjaro, you have to use pacman:
sudo pacman -Sy testdisk
Using testdisk
Although it runs in a terminal window, testdisk does have a rudimentary interface. You use the arrow keys to navigate and Enter to make a selection. To keep things neat, it’s best to create a directory for restored files.
We type the following to create a directory called “restored” for our restored files:
mkdir restored
We type the following to switch to the new directory and start testdisk from there:
cd restored/
We have to use sudo with testdisk, so we type the following:
sudo testdisk
The first question testdisk asks is about logging. It can create a new log file, use an existing one, or not log anything at all. It doesn’t matter which option you choose; it won’t affect the way testdisk operates.
You can just press Enter to accept the highlighted option and create a new log file. It will be created in the directory from which you started testdisk. When you make your selection, testdisk asks which hard drive holds the file system on which you want to work.
It lists the hard drives it can find, as well as the squashfs “/dev/loop” files. There’ll be one of these for each application you’ve installed from a snap. They’re read-only, so you shouldn’t have managed to delete anything from these file systems.
There’s only one physical hard drive in this test computer, so we used the down arrow to highlight the “/dev/sda” option. We then used the right arrow to select “Proceed,” and then pressed Enter.
testdisk also needs to know the partition type. It presents a menu of options, along with the type of partition it’s autodetected at the bottom.
Unless you have a good reason not to, highlight the type of partition that’s autodetected, and then press Enter.
In the function menu that appears, highlight “Advanced,” and then press Enter.
The partition selection menu will appear.
The files we’re looking for are in the Linux filesystem partition. We only have one Linux partition on our hard drive, but you might have more.
Select the partition your files were on, use the left and right arrow keys to select “List,” and then press Enter. The file-selection menu will appear.
Use the up and down arrows or the PgUp and PgDn keys to navigate the list of files and directories. Press the right arrow or Enter to enter a directory, and the left arrow or Esc to exit a directory.
We’re looking for files that were owned by dave. The files for all user accounts are in the “Home” directory. So, we highlight the “Home” directory, and then we can press either the right arrow or Enter to enter that directory.
All the user accounts are then listed for us. We highlight dave, and then press the right arrow or Enter to enter that directory.
We can now see the files that belong to the dave account. The entries in red have been deleted. We navigate through the files and directories until we locate the files we want to recover.
To recover a file, just highlight it, and then press c (lowercase).
The display changes and tells you to choose a destination for the recovered file. Because we created a directory called “Restored” and started testdisk from it, the first entry in the list (.) is that directory. To recover this deleted file to that directory, we press C (uppercase).
After you do this, you’re returned to the file-selection display. If you want to recover more files, just repeat the process. Highlight a deleted file, press c (lowercase) to copy it, and then press C (uppercase) to recover it.
Working with Restored Files
After you restore a file, the directory tree to its original location is reconstructed, which is useful because it reminds you where on the hard drive the original file used to reside. This means if you need to copy it back, you know where to put it.
If you recover a number of files from different filesystem locations that happen to have the same file name, they’ll need to be stored separately anyway.
You can type the following to see the contents of the “Restored” directory:
ls
If you asked testdisk to create a log file, it’ll be in the “Restored” directory. Because our recovered files were located at “/home/dave,” they’ve been copied to our “Restored” directory, nested in directories with the same name.
We can change into the copied “dave” directory using cd. Make sure you don’t include a leading forward slash (/) on the path—you want to change into the local “home,” not the system “/home.”
We type the following:
cd home/dave
The recovered files are in that directory, so we type:
ls
Let’s take another look at the recovered files using the -l (long listing) option:
ls -l
Because we used sudo to launch testdisk, the recovered files have been restored with “root” as the owner. We can change the owner back to “dave” using chown:
sudo chown dave.dave *
We type the following to make sure the correct ownership has been restored:
ls -l
testdisk: Code for Relief
That feeling of relief after you recover an important file that, just a moment ago, felt irretrievably lost, is something you’ll always appreciate.
That’s why testdisk is such a handy utility. After you make it through the menus and can start restoring files, it’s easy to fall into a rhythm of highlight, c, C, repeat.
Recent Comments