- About Us
- NAS Data Recovery
- A-Z of Data Recovery
Data Recovery From EXT Linux RAID
The EXT2 File System
When a file in EXT2 is deleted, its inode changes status from “used” to “free” space. However, the inode structure will still contain pointers to the data blocks and the data blocks are not deleted until they get overwritten. This often makes data recovery from EXT2 partitions possible.
The EXT3 File System
The EXT3 file system is commonly used by NAS devices and RAID servers. It is important to understand how EXT3 handles data differently from other file systems and how knowledge of these differences can be used to successfully recover data.
EXT3 uses an indirect block mapping system, where one-to-one mapping of logical blocks to disk blocks takes place. This is very efficient for small files, but incurs a high overhead for larger files.
EXT3 is a journaled version of EXT2. This means that a log file of system changes is recorded before disk writing takes place.
The journal superblock is a data structure that is found 1024 bytes from the start of the EXT file system. It records information as to the block size, journal size, the total number of unused blocks that the journal has for storage, where the journal starts and inode allocation information.
The main advantage of EXT3 over EXT2 is its use of journaling. The usefulness of the information extracted from a journal will be determined by the type of data recovery that is being performed. Old inode data may be present in the journal, which can provide a transaction log of old time stamps or old ownership information. Moreover, old inode data recovered from the journal may contain block pointers which have been wiped from a deleted inode.
The EXT4 File System
While EXT3 has been a very popular file system because of it’s reliability, features and good performance; it has limited ability to scale and work with large configurations. As a result, developers started to work on a new version that would handle large disk sizes better. Enter EXT4.
EXT4 can handle individual file sizes of up to 16TB. The file system itself can support disks up to 1 exabyte. EXT4 uses CRC32 checksumming. For each transaction, the CRC is executed over all of the transaction blocks. But here is the clever bit, if the file system has to perform a recovery and the checksums do not match, then the transaction is regarded as invalid. While checksumming does incur an IOPS overhead on the file system, it is offset by the fact that the actual transaction and journal writing occur simultaneously. This means that the speed of the EXT4 file system over EXT3 can be up to 20 percent faster.
Data Recovery from EXT4
Even though EXT4 has earned the trust of users worldwide as a robust file system, there are occasions when the data on an EXT4 volume will become lost or inaccessible. This can be attributed to a number of reasons, including file system problems (such as inode or metadata corruption) or caused by physical problems with one or more of the disks.
The ability to recover data from a corrupted EXT4 volume is usually determined by the size and fragmentation of the volume’s files. The smaller the file and the fragmentation, the better the probability of recovery. Even if your files do not meet this criteria, all is not lost. Extent headers can often be used to identify index blocks. Extent headers can be used to find exactly where tree hierarchy blocks should be placed. Examination of un-initialised extents and group descriptor growth blocks can also prove fruitful.