For those in the RAID data recovery field, those instances of data recovery that are most interesting are when there are multiple issues to contend with. Therefore when you combine a RAID failure with the deletion of files from a UNIX UFS file system this gives rise to a very challenging data recovery proposition. The first aspect of the recovery process is in securing data. Reputable data recovery services, of which there are many, will ensure that they have secured all the available data before they start any further data recovery processes. Those reputable data recovery business will not work on the disks from a RAID before having ensured that they have image copies of each. Those data recovery business that do not do this and therefore risk total data loss are to be avoided at all costs. Your most important step is to ensure you are using the services of a reputable data recovery business. For these businesses it is a comforting fact to know that there are a variety of tools available to data recovery specialists to image copy working disks. 1st Step - Define the RAID There is no universally standard RAID 5 organization. RAID 5 is a description of 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, however the order which the disks are used, the order of how the parity is distributed across the disks and the size of each block of data on each disk is not. This is where the UFS (and EXT3 and XFS) format of splitting a volume into allocation groups is a big advantage. With the NTFS all you really get is the start of the MFT and the MFT mirror. There can be many RAID 5 organizations that result in these being situated correctly, so there is a great reliance on analyzing the file system to enhance 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. 2nd Step - Analyze the data When you have established the RAID organization the next step is to locate the required data. There are so called data recovery experts who will state that deleted file data recovery from a UFS volume is not possible. There are good reasons for this statement however it is not entirely an accurate statement. Initially consideration must be given to the manner that UFS manages the data allocation of data for files. Every file is described by an inode, this is where the information pertaining to the dates and times, size and allocation of a file are stored. The allocation itself is a variety of pointers to the blocks of data that form a file, as well as some indirect block pointers. When a file has been deleted the inode is available for re-use and the allocation information therein will be removed. This however does not mean that there is no way of using a specific program to scan those inodes for the deleted files. This is a process of scanning the MFT entries of an NTFS file system to undelete files. You do however need to have knowledge of what files are to be recovered. Most types of files have identifiable header information, and for others there may also be earlier versions that can be located on backups for similarity. From this point a required understanding of how the files are allocated under UFS is need as well as what additional structures are used. With this information it can be possible to recover selections of files even when the primary allocation information has been removed. UNIX Data Recovery This particular approach to UNIX data recovery has achieved some worthwhile and notable success. However it would be incorrect to state that data recovery is always feasible. With large data files such as databases, the level of success has been high. With file systems that have large amounts of smaller files with more extensive file deletion the level of success is often not as notable. This is especially true without the inode for any file, unless there is a log of inode numbers. Without this information it will never be realistic to associate any of the recovered files with file and directory names. The overall point therefore is that it is incorrect to state that files will always be recovered. The more correct phrase would be to state that it is often that files can be recovered and that without further investigation it will not be possible to confirm recovery either way.
Please Rate this Article 5 out of 54 out of 53 out of 52 out of 51 out of 5
Not yet Rated
