Data recovery is at it’s most interesting when there are multiple issues to contend with, so combining a RAID failure with the deletion of files from a UNIX UFS file system gives rise to a particularly challenging data recovery.
Secure the data
The first aspect of the work is the securing of data. Any reputable data recovery company, and there are many, will religiously secure all available data before beginning any work. Working live on the disks from a RAID without first having secured image copies of each, and risking total data loss should there be any hardware failures or write backs, is morally indefensible and commercially inept. There are many tools available to image copy working disks.
Define the RAID
There is no standard RAID 5 organization. RAID 5 describes a method of striping data across a number of disks with the creation of parity XOR data that is distributed across the disks.
The parity data calculation for RAID 5 is straightforward, but the order in which the disks are used, the order in which the parity is distributed across the disks and the size of each block of data on each disk are not.
This is where the UFS (and EXT3 and XFS) method of dividing a volume into allocation groups is a great benefit. The NTFS all you really get is the start of the MFT and the MFT mirror, and there can be several RAID 5 organizations that result in these being positioned correctly, so there is a great dependence upon analyzing the file system to augment the analysis process. With UFS there is a copy of the superblock followed by inode tables and allocation bitmaps at equally spaced positions throughout the volume. This makes determining the RAID configuration relatively straightforward in most UNIX data recovery cases.
Analyze the data
Having worked out the RAID organization the next challenge is to track down the required data. There are many who claim that deleted file data recovery from a UFS volume is not possible, and there are good grounds for this claim, but it is not entirely accurate.
To begin with we must consider the manner in which UFS manages the allocation of data for files. Each file is described by an inode, this is where information pertaining to a files dates and times, size and allocation are stored. The allocation is a number of pointers to the blocks of data that form a file, plus some indirect block pointers. When a file is deleted the indode is free for re-use and the allocation information therein is removed. This does mean that there is no method of using a program to scan the inodes for deleted files in the way that can be done by scanning the MFT entries of an NTFS file system to undelete files.
What is required is knowledge of the files that are to be recovered. Most types of files have identifiable header information, and for others there might be earlier versions that can be found on backups for comparison. Thereafter is needed an understanding of how files are allocation under UFS and what additional structures are used. Armed with this knowledge it is quite possible to recover a selection of files even though the primary allocation information has been removed.
UNIX data recovery
This approach to UNIX data recovery has achieved some noteworthy successes, but it would be wrong to claim that data recovery was always practicable. For larger data files, for example databases, the level of success has been high. For file systems that contain large numbers of small files and where there has been widespread file deletion the level of success is not usually as high, especially as without the inode for any file, unless there is a log of inode numbers, it will never be practicable to associate any of the recovered files with file and directory names.
So, rather than make the outrageous claim that files can always be recovered, it is better to state that they often can and that it is wrong to decide that something is impossible until all avenues have been explored.
