Professional Data Recovery

When all the allocation information for a file is lost sometime the only way to recover the data is to trawl and scan every block of data looking for the remains. When Microsoft changed there Exchange data structure our job in data recovery got a whole lot harder.

The popularity of NAS RAID units has never been higher, but whilst RAID5 gives a high degree of reliance against the failure of any one disk in the NAS unit, other problems can result in data loss requiring data recover, and that could easily have been prevented by the implementation of a simple backup regime.

There are times of the year when old, obsolete tapes seem to creep out of the woodwork for emergency data transfer. In all probability it had been thought unlikely that any data from them would ever be needed, or at least that was the hope. This month has seen a number of TK50 data recovery jobs, tapes last used in any significant volume back in the 1980s. Sadly, had these tape been dealt with a few years ago there might not have been problems, but decay during storage has now resulted in a large number of problems requiring data recovery.

A tape archive is more than just a place to keep data in case of a problem, it is part of your data and could form part of any eDiscovery request from a number of regulatory authorities. Trying to locate and recover data from a large off-line store when under a tight deadline can be difficult, sometimes impossible, so is it time to consider a data migration process to ensure that you are prepared?

In the past 15 years the data recovery industry has changed. Previously the domain of only computer geeks, the emergence of data recovery software tools on the market has meant that anyone capable of pressing the 'go' button can claim to be a data recovery expert. But what happens when the problem is too complex or doesn't fit the profile? Just because the software can't cope, doesn't mean your data can't be recovered.

Even when a file does have a recognisable header and footer it can generally only be recovered in such a way if the file data is contiguous. For UFS and many other UNIX/Linux files systems does not occur in large files because they will have allocation and other file system structure data interspersed. The recoveries on UFS file systems that we have recently been seeing were generally for large, multi gigabyte, files. UFS uses direct and indirect data allocation information, direct being pointing to file data and indirect pointing to allocation information that then points to file data. File deletion will destroy the direct allocation information when the inode is destroyed however the indirect allocation remains. The heads of the files were found manually. We were able to use file system information to refine our search rather than just trawling the entire data space. We then mapped out the used,…

It seem that you are hinting to the fact the if the deleted files have a clearly identifiable header and footer then it can be reassembled manually the old-fashion way before all the tools were available. Is that correct, or are you saying that there is a "hidden" or less know source of a file allocation info beside the inode?

Thank you for your comments. I should begin by making clear that I did not intend claim that the entire tape will always have to be read for each restore, but sometimes either all or a significant proportion might have to be read, and I apologise if I gave the wrong impression. NetBackup organises data along a tape in sequential sections named "fragments". Each fragment is a number of data blocks terminated by a tape file mark. The fragments of a single image (backup) can be distributed over many tapes and in a multiplexed backup each of these fragments can contain data from a number of different images. I agree that NetBackup can reference the catalog to identify only the fragments that are required to restore a specific image and skip any fragments that do not contain data relevant to the restore, and that this can dramatically reduce the area…

You said "For example, one backup set might occupy only 10% of the space on an LTO4 tape, but the restoration might require that 100% of the tape be read as each block must be read to see if it belongs to the required backup set." NetBackup doesn't work that way. In general we would be skipping ahead as needed to just the data we need. There are exceptions of course, but you shouldn't have to read 100% of the tape. One exception might be if you have lost the NetBackup catalog and you need to recreate that from scratch. This underscores the neccessity of maintaining a good backup of the NetBackup catalog and practicing disaster recovery scenarios. If you have questions feel free to email or comment. thanks, Tim Burlowski Product Manager Symantec