Anyone who has worked in Linux has deleted a valuable file at least once, or even the entire root directory! rm -rf is the most alive, there is no backup copy (but it should be!), time for searching and choosing utilities for recovery – too. How to be?
In 2006, Chris Kaspersky's book "Data Recovery" was published, which quickly became a bestseller. Now this book is being prepared for reprint. We are publishing an excerpt from this book dedicated to data recovery on ext file systems.
Mistaken deletion of files in * NIX is a fairly common occurrence, perhaps even more frequent than in the Microsoft world. Under Windows, most file operations are performed manually using Explorer or other interactive tools such as FAR or Total Commander. There are interactive environments in Linux (KDE, GNOME, XFCE…), but a large part of Linux fans are command line fans. The command line, on the other hand, is about regular expressions and scripts — that is, automated controls — powerful, convenient, and, if misused, destructive. The slightest carelessness – and you can say goodbye to your files forever!
To paraphrase Bulgakov, we can say: not only is the file mortal, but it is also suddenly mortal! Trouble never warns of its arrival, and the administrator has to be constantly on the alert. A few seconds ago, everything was fine: spring was blooming, the Winchester was chirping animatedly with all its heads, the administrator was sipping coffee from a black mug with the inscription root, when suddenly hundreds of gigabytes of the most valuable data were suddenly scattered into small pieces. All forces are thrown into clearing the rubble and saving everyone who can still be saved.
The availability of the source code of the file system driver greatly simplifies the study of its internal structure, which, by the way, is very simple. Therefore, data recovery on ext2 / 3/4 partitions is a trivial task.
Meet! Extended file systems family
Initially, Linux was something of a free retelling of the Minix OS, development was carried out under it, and the first versions of Linux worked on the Minix file system. The name was plain – MINIX file system – and, in turn, was inspired by the UNIX file system – UFS. But since Minix itself was developed more for educational purposes, its file system did not have extensive capabilities. For example, the size of a partition could not exceed 64 MB, and the maximum file name length was 14 or 30 characters, depending on the version. To overcome such limitations, they began to develop their own FS for Linux.
A little about the origins
The new file system extended the capabilities of MINIXfs, for which, apparently, it was called the extended filesystem. The first implementation of the extended filesystem, ext fs, saw the light of day in 1992 in the Linux kernel 0.96c… Linux aficionados were now limited to two gigabytes per partition, and files could have names up to 255 characters long. Nevertheless, this FS was still relatively simple, so its further development was not long in coming. Around the same time, by the way, Linux introduced a virtual file system (VFS) abstraction layer that made it easier to add support for new file systems to the kernel.
With ext2 a couple of years later, the maximum file and file system sizes increased to 16 GB and 2 TB, respectively (at a block size of 1 KB). Some of the blocks (usually 5%) were now reserved for root, not allowing ordinary users to fill the entire section without a trace. Then this FS became almost the de facto standard on Linux, and its implementation, they say, was under NT…
The third extended file system (ext3) appeared almost twenty years ago in one of the versions of Linux 2.4.14… It is very similar to its predecessor, ext2, but differs in support of journaling (in NTFS terminology – transactions). Unlike ext2fs, it is much more careful with the directory array, although, as we will see a little later, this will not help us much.