Undelete file ext3

If you deleted more than one file in a directory or a directory itself, you can use --restore-directory :. There are some more useful options as --restore-all , --restore-files, --after 'dtime' or --before 'dtime', but in the most cases the two examples above should be enough. Lo and behold! Carlo Wood created just the tool you had imagined! Like many UNIX filesystems, ext3 represents files with a data structure called an inode. The inode contains metadata such as what user owns a file and the last time it was modified.

When a file is deleted from disk, the blocks containing the file contents are not modified immediately; only the inode is changed.

The blocks are simply freed up to be overwritten as space is needed in the future. On ext2 filesystems, the inode is marked as deleted, but the pointers are left intact.

Ext3 actually zeroes-out the inode pointers, making it impossible to retrieve the file contents from a deleted inode. Inode Pointer Structure. However, trying to restore large or non-plaintext files via this method e. Instead of trying to find the information that points to where the deleted file data is on the disk, it tries to find the data by parsing the data itself to identify files.

This method is less targeted than extundelete, but may still work if the information pointing to the file has been deleted from the journal. Photorec can find deleted files of a particular type. Photorec seems to be well supported on the main distros, so you should be able to find a package for easy install. Rather than list the process in detail here, there is a very good explanation of the steps on the photorec wiki. Happy undeleting and remember prevention is always better than the cure.

Fortunately, you remember that files are never really deleted, at most overwritten by new content. So, you remount the disk read-only as fast as possible. But now? If you Google for "undelete ext3", almost every article you find will be users asking if it's possible and the answer is every time: no.

The most frequently quoted passage comes from the ext3 FAQ itself:. In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone. Your only hope is to "grep" for parts of your files that have been deleted and hope for the best.

However, this is not necessarily true. All information might still be there, also the block pointers. It is just less likely that those are still there than on ext2 , since they have to be recovered from the journal. On top of that, the meta data is less coherently related to the real data so that heuristic algorithms are needed to find things back. Every time a file is accessed, it's Access Time is changed, and it's inode is written to disk, along with 31 other inodes that reside in the same block.

When that happens, a copy of that block is written to the journal. Therefore, if your partition isn't too large compared to your journal, and if you at least recently accessed the files you want to recover, you might be able to recover the block pointers from the journal. On February 7th, , I accidently deleted my whole home directory: over 3 GB of data, deleted with rm -rf. The only backup that I had was from June Not being able to undelete was unacceptable.

So, I ignored what everyone tried to tell me and started to learn how an ext3 file system really works, and what exactly happens when files are deleted The tool that I wrote assumes a spike of recently deleted files shortly before the last unmount. It does NOT deal with a corrupted file system, only with accidently deleted files. Also, the program is in a beta stage: the development of the program was done as a hack, solely aimed at recovering my own data.

After I recovered my data I have continued development for one more month to address bugs that didn't show in my case, but over all the program isn't as robust as it could be. Therefore, it is likely that things might not work entirely out-of-the-box for you. I stashed the program with asserts , which makes it likely that if something doesn't work for you then the program will abort instead of trying to gracefully recover.

In that case you will have to dig deeper, and finish the program yourself, so to say. The program only needs read access to the file system with the deleted files: it does not attempt to recover the files. Instead, it allows you to make a copy of deleted files and writes those to a newly created directory tree in the current directory which obviously should be a different file system. The name of the program, ext3grep was chosen because I was planning to write a highly intelligent program that would be able to reconstruct files by searching for blocks that looked similar to expected blocks based on an old backup, or other rules.

The grep in the name was in anticipation that the quote from the ext3 developer was true: I was preparing for the need to work with sets of blocks, each set corresponding to a search pattern and weighted with a likeliness, upon which then one would have to work with set operators in order to reduce the number of blocks and assign them to files, and give them their order.

However, nothing like it turned out to be needed. Nevertheless, I kept the name ext3grep because someone might want to add a true grep -like functionality to the program at this moment it's grep-functionality is limited to fixed strings, printing matching block numbers to standard output. The content of files is stored in contiguous blocks of bytes the actual size depends on command line parameters passed to mke2fs when the file system was first created and can be , or bytes.

This doesn't necessarily mean that the minimum size of a contiguous file fragment is of the same size although it can only be smaller , but in practise it is. In fact, the program will not work if the fragment size is unequal the block size. The actual block size, as well as the actual fragment size, are stored in the superblock and can be retrieved with the option --superblock.

For example,. Here IMAGE is an environment variable that was set to the name of the device or a copy thereof made with dd of the partition holding the file system. Normally only root can read devices directly, but you can temporarily make them readable by you, of course, or make a backup image with dd.

The entire partition is divided into an integral number of blocks, starting to count at 0. Thus, if you ever want to make a copy of block number N, you could do:. Where N runs from 0 till but not including the number of blocks as stored in the superblock. Having any block number, one can print information about it by using the command line option --block. The superblock isn't really a block.

It's size is always bytes and the first superblock starts at offset Thus, if the block size is then the superblock is block 1, but if the block size is or , then the superblock is part of block 0. There are multiple backup copies elsewhere on the disk. The data of the unsigned integers is stored on disk in Little Endian format. Each ext3 file system is devided into groups, with a fixed number of blocks per group, except the last group which contains the remaining blocks.

The number of blocks per group is given in the superblock, ie. Another block is used as bitmap for the number of allocated inodes.