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 vital 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, but 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 huge 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 fantastic 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 RAID data recovery experts who will state that deleted file data recovery from a UFS volume is not possible. There are excellent reasons for this statement but 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 but 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 but 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. But 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 right 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 right 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.

The post RAID & UNIX UFS Data Recovery – Is Data Recovery Always Possible? appeared first on .

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 fantastic 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 fantastic 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 excellent grounds for this claim, but it is not entirely accurate.

To start 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 incorrect 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 incorrect to choose that something is impossible until all avenues have been explored.

The post Raid Data Recovery And Unix Deleted Files appeared first on .