RAID Data Recovery Services

DTI Data Recovery is one of the few companies that actually performs RAID recovery in their own labs. RAID data recovery is the most advanced type of data restoration there is. Not only do the hard drives need to be repaired, but the underlying file system or parity needs to be re-written or restored.

RAID Hard Drive Data Recovery

A RAID system is very complex at every level. There are many things that can and often DO go wrong. The most common problem involves hardware and specifically the hard drives that make up the RAID. While there are many types of RAID systems, the most common is a RAID 5 which requires at least 3 hard disk drives to function. It will work as long as 2 of the drives are functioning. If 2 hard disk drives fail then there is no alternative but restore from backup or look for a company like DTI that does RAID Data Recovery.

If you have read any of the previous articles in this blog you know that hard drives fail and that they fail often. A system that requires at least 3 hard drives is that much more likely to have a hard disk problem. Since most companies that employ RAID systems use the RAID itself as backup as well as storage. So how do you back up your backup? The fact is even a totally redundant RAID system like a RAID 10 which is a mirrored RAID 5 can fail.

DTI generally only needs the hard drives to perform RAID Data Recovery. If you are shopping around for RAID data recovery and a company is asking for the whole system, don’t send your data to them! At most the RAID card would be the only thing a real data recovery company should need and that only when there is a question about parity or block size or type. Some information can only be gotten from the card. A company like DTI Data Recovery has basically seen all the RAID cards that there are.

If there are physical problems with the RAID then hard drive repair will have to be done prior to the actual data recovery of the RAID system. Once the hard drives have been repaired enough to be copied sector by sector and the sector data has been transferred to similar or the same media then RAID Data Recovery can begin.

RAID Data Recovery With Software

There are a few data recovery programs that can work with damaged RAID systems. In some cases the RAID volume can be created virtually. Images are made of the hard drives and they are put back together again in a virtual environment. One of the problems with this type of recovery is often time the images don’t align properly and the headers need to be modified with a hex editor. This is serious business and is very difficult unless you have advanced programming knowledge.

DTI Data Recovery has the type of programmers and engineers that are required to put back together a failed RAID system. Once the hard drive have been safely cloned then the work truly begins. Only with the cutting edge technology that is proprietary at DTI Data can RAID arrays be successfully restored. Don’t risk your data, call DTI if you require RAID Data Recovery.

If you are unsure of what to do please call 866-438-6932 for a no cost no obligation RAID Data Recovery evaluation.

24 Hour Hard Drive Recovery & Server/RAID Support Hotline:
Toll Free 1-866-438-6932 or direct 1-727-345-9665.

Extended Software Support:
8 AM to 11 PM EST 7days a week!

SNAP Data Recovery Through The OS Inode

This week is the final offering of our topic Recovering a single file from a SNAP Server Operating System. We have learned what a Super Block is, a cylinder group, and some of the important data elements in those data structures. We have learned how to find these data structures by using the data elements of other structures. Finally, we have learned that the file system is broken into blocks and that these blocks are the storage cornerstone of SNAP OS. Putting all of these facts together we come down to the final data structure the inode. At the bottom of this article there are links to my other posts so you can read or print them all in order.

Recovering a single file from a SNAP OS Part 3

The inode is the final link in the chain of data storage.  It holds the map of the blocks where all of the data of each file and directory is stored. Let us dissect the inode and find its most important elements.

The SNAP OS Inode

Figure 1 is a raw hex representation of an inode. There are several data elements within the inode that define the date the file or directory was created, the last time it was updated, and the size of the file. For our purposes however, we are only concerned with one area of data elements and those are the direct and indirect block definitions. 

Fig 1

The direct block definitions are defined in the shaded green area, and there are a maximum of twelve direct data blocks. The term direct means that each one of the four byte numbers in the shaded green area point to an actual data storage block. In other words, if we take the first value of 0×14A80E (1353742 decimal) and go view that data block, we will find the first values for our file 2003STEP.PDF. In figure 2 we can see the first few bytes of data from block 0×14A80E.

Fig 2

There are only twelve direct data blocks so if your file exceeds 96 k, then the file system will use a method defined as indirect blocks. There are three data elements of these blocks, they are:

• Indirect Block: Points to a block that has a list of data blocks.
• Double Indirect Block: List of blocks that point to an Indirect block.
• Triple Indirect Block: List of blocks the point to Double Indirect blocks.

From the above explanation you can see how deciphering a very large file can be extremely complicated. Once understood, this method works well and is very fast. Along with those facts, it is also very easy to program using recursion and a set of flags to let the recursive function know what is being processed. 

Figure three is a listing of the 2003STEP.PDF direct blocks from its only indirect block.

Fig 3

Well, that’s it!  By using the formulas and techniques I have outlined in my last three articles you can easily retrieve any file. I hope this helps those of you that have lost data due to hardware and or software failures on your SNAP Server.

If you have any questions, or if I can be of any help, please feel free to call me, or drop me an email.

(727)345-9665 Ext 203

dickc AT dtidata.com

SNAP Server Data Recovery of a Single File

Here are all the articles about SNAP Server Recovery of a single file:

1. SNAP Data Recovery - the first post about the SNAP OS.
2. SNAP Server Data Recovery of a Single File - A detailed post about recovering a lost file on the SNAP OS.
3. SNAP Server Data Recovery Using The Super Block - the next article about SNAP file recovery.

Our main page for SNAP Server Data Recovery.

RAID Data Recovery

DTI Data Recovery is one of the few companies in the US that are qualified to perform RAID data recovery. One of the hardest types of recovery, a RAID Array Restoration involves many different levels. A lot depends on the type of RAID, is it software or hardware based, is it a RAID 0, RAID 1, RAID 5 or RAID 10. The different levels of RAID along with the block size and file system is information that the RAID engineer will need to give you a quote.

RAID Levels and How They Affect Data Recovery

A RAID array can have many different levels. RAID’s can be anywhere from RAID 0 to RAID 50 with everything in between. Each has a different function and reason for implementation.

RAID 0 Data Recovery

The hardest RAID to recover is a RAID-0. A RAID 0 is a striped or spanned set where two hard drives are serving as one volume. This type of RAID is being used more and more in gaming machines and a lot of home computers due to the additional disk size and speed the data can be accessed at. The problem with a RAID 0 is if one of the hard drives fails for a physical reason, it MUST be recovered prior to data recovery of the RAID 0. Since the volume is spanned parts of files like a database could in fact be housed in part on both drives!

If you have a RAID 0 that has failed make sure the data recovery company you are sending your array to has a clean room like DTI Data. If not there is little chance they will be able to recover a RAID 0 with a physical hard disk problem.

RAID 1 Data Recovery

A RAID 1 is a mirrored array. One drive is an exact copy of the other drive. If one of a RAID 1 array disk fails then it is possible to recover the data off of the other drive. DTI has been successful many times being able to recover data with only 1 of the RAID 1 drives.

RAID 5 Data Recovery

A RAID 5 array is a mirrored stripe set. In a 3 drive array only the space of 2 of the drives is available for storage. The parity is spread throughout all 3 drives. With a RAID 5 recovery, only 2 of the 3 drives must be accessible for data recovery. If more than 1 drive has had a physical failure, then the RAID data recovery company must get at least 2 or a 3 drive RAID array working.

RAID Operating Systems and Data Recovery

Since physical recovery of a RAID depends upon what level of RAID is being used, a logical RAID failure would seam to be an easier restoration. The fact is that logical RAID data recovery is often the hardest part of RAID restoration. Whether it is a RAID 0 or a RAID 5, once the hard disk drives have been repaired enough that our engineers can access the drive, the programmers now need to rebuild the file system.

Before you decide to send your failed RAID array to anyone, make sure they have the same capabilities as DTI data. We have in-house programmers that can rebuild parity, file systems, partitions, and all the other things that can fail in a RAID array.

Many times on a RAID 5 the parity that runs across the drives is damaged along with one or more hard drives. At this point our engineers have developed a proprietary method that de-stripes the array and creates a new volume. This allows the data and files to be recovered.

If you have any types of problems with an array and you need RAID Data Recovery, please contact DTI Data at once! Don’t try to rebuild the array without consulting one of our engineers. Our RAID engineers are ready to help you 24 hours a day.

Call us now toll free (866)-438-6932 or direct (727)-345-9665.

*Note: If you are unable to contact an engineer after hours on our main support line feel free to call our Exchange Server  24 hour hotline at 727-251-2058 for after hours RAID data recovery support.

SNAP OS Data Recovery Super Block

SNAP Operating System File Recovery Through The Super Block

Recovering a single file from a SNAP OS Part 2

Last week we discussed how to find the file name on a SNAP OS file system. Using a sector editor we searched the hard disk drive for the file name. Once we found the file name I broke down the on disk data structure format for a directory/file entry.  Among the many elements of the structure the most important in determining where the data for the file is stored is the inode number. In this weeks installment we will discover how to use the on disk data structure called the super block. This is the key to the entire file system and is essential if we are to find the data related to this file name.

In order to find the super block, we must first understand how the SNAP OS positions itself on a drive. In windows the basic element of storage is a cluster. Standard cluster size for an NTFS drive is 4096 bytes, or eight (8) sectors. For SNAP OS the basic element of storage is a block. Standard block size for SNAP OS is 8192 bytes or sixteen 16 sectors. Using the block as a basis for storage, we then have groupings of blocks. These groupings of blocks are called cylinder groups. The on disk layout of a cylinder group is as follows.

Cylinder Group On Disk Layout

All blocks are relative to the beginning of the cylinder group.

• Super Block: Block 0: This block houses a copy of the on-disk structure of the super block
• Cylinder Group: Block 1:  On-disk structure of the cylinder group
• Inodes: Block 2 – (2 + n)  Inode StorageEach inode is 128 bytes, therefore 4 inodes per sector, or 64 inodes per block.
• Data Blocks: Blocks (2 + n)  - (end of cylinder group)  All remaining blocks to the end of the cylinder group are data blocks.

Applying real world numbers

In order to help illustrate how all of this works together, let’s take the 2003STEP.PDF example and apply it to our on disk definitions.

First of all, we must find the super block. The best way to do that, is to find the first cylinder group using the magic number I spoke of in my article “SNAP RAID Recovery Using SNAP OS”. The magic number for the cylinder group is 0×550209.  So, using WinHex as my sector editor, I plug that value into the “Hex Search” field and run the search.  In this case the Cylinder Group is stored at sector 48.  Now, we know that the Cylinder Group data structure is stored in relative block 1, and we also know that a copy of the super block is stored in relative block 0. The size of the blocks is 8K, so, we can count back 16 sectors, or 8K and find a copy of the super block.  

So, a copy of the super block is stored at sector 32.  There are some data elements within the super block that will help us identify the exact placement of the inode we are looking for. These elements are as follows: (Remember the numbers are for this real life situation only, your numbers may differ because of disk size, formatting flags etc.)

Super Block Offset:               2

Cylinder Block Offset:          3

Inode Block Offset                4

Data Block Offset                  16

The above numbers are relative to the beginning of the volume. Therefore we can find the beginning of the volume by using the Super Block offset.  The Super Block is stored on block two, or translated to sectors, sector 32. If we subtract 2 blocks, to find block zero, which is the beginning of the volume we will find the beginning of the drive.  This is important since many of the SNAP OS volumes I work on are RAID-ed. There is a great deal of extraneous data when dealing with RAIDs, however, using this formula, we can easily find the beginning of the drive on a destriped RAID set.

Secondly, and more importantly, we can determine the total inodes per cylinder group.  As defined before, we know that there are 64 inodes per block.   In our real world example we can see that the inode block starts at relative block 4, and the data block starts at relative block 16.  If we subtract 4 from 16 we know that there are 12 blocks of storage per cylinder group.   We know that there are 64 inodes per block, times12 blocks, or 768 inodes per cylinder group.  There is a data element in the super block that tells us the inodes per cylinder group.  If we take our previous calculation, and it matches the super block data element, then we know that our file system is aligned.  In this case they both match.

Now, if we know that we have 768 inodes per cylinder group, and the current inode we are looking for is 1015297, we can divide the inode we are looking for, by total inodes per cylinder group to find the cylinder group which house our inode. That value 1322.   We then do the mod of the same values to tell us which inode within the cylinder group is the one we are looking for.  That value is 1.  So, we can say in cylinder group, 1322, inode 1, we have the inode we are looking for.

Lastly, how do we find Cylinder Group 1322?  The size of the Cylinder Group is the size of the data group plus 64 sectors.  So, in my case, the data group was 1024 blocks, or 16,384 sectors.  You add 64 sectors to that and you have each cylinder at 16,448 sectors.  One note, every 16 cylinder groups is an adjustment of 1024 sectors.   So the 16th cylinder group is only 15,424 sectors.

That’s, it!  Now that we have a method for finding the inode, we can actually start pulling data off.  I will cover direct disk blocks and the formula for pulling data off of the drive in my next installment.

SNAP Server Data Recovery Of A Single File

Recovering a single file from a SNAP OS

As we know SNAP Appliance used a proprietary Unix File System (UFS) handler in order to run there Network Attached Storage (NAS) product. This particular OS ran a Berkley Software Distribution (BSD) flavor of UFS. Although there are many similarities to the original file system, there are also enough changes to make file recovery extremely difficult. In the following paragraphs, and articles we will explore the arithmetic and methodology of recovering a single file from a UFS volume.

In order to recover the file we must use the on-disk data structures that give the OS its road map to the file name, inode, and finally data block placement. Normally I would start with the coarsest data structure, but in order to facilitate an understanding of the file hierarchy I will start from the smallest granularity. That data structure being the directory entry.

To illustrate the data elements and their use I chose a PDF file for recovery. The file name is “2003STEP.PDF”. Using you favorite sector editor, do a scan and search for the file name that you want to recover. The tool I use is a wonderful product called “WinHex”. Figure A is a capture of my sector search.

Figure A

There are many elements in a directory entry structure; however there are actually five key elements.

1. File Name: This is the actual name of the directory/file. In Figure A this is defined as “2003STEP.PDF”
2. File Name length: This data element is self explanatory as it defines the length of the name. In Figure A the name length is defined as 0×0C, or 12 in decimal.
3. File Type: In this case we are only concerned about two types. First 0×04 which is a directory entry and 0×08, which is a standard file name entry. In Figure A this file entry is regular file name.
4. Record length: This defines the entire length of this particular directory/file name record. In variable length records there is always a record length. In Figure A you can see the record length is 0×00000028 in hex, or 40 in decimal.
5. Inode number: The name, and name length are important, however the inode number holds the key to the data block placement. In Figure A this is defined as 0×000F7E01, or 1015297 in decimal.

Next installment I will describe the ‘cylinder group’ data structure and how we can use that to find our inode element.

SNAP RAID Recovery using SNAP OS

SNAP Server NAS RAID Data Recovery

SNAP Appliance, now owned by Adaptec was one of the pioneers of the Network Attached Storage (NAS) technologies. Through the use of  the Berkeley Software Distribution (BSD) and the UNIX File System (UFS), SNAP developed a reliable and easy method for using a mass storage device through a shared network.  In order to do this SNAP used an abbreviated version of the file system in conjunction with a set of hard coded variables that allowed for a fast boot up, easier recovery facilities within the spectrum of the operating system, and a ROM based web interface that was closely tied to several of the standard UNIX/Linux/BSD recovery tools. However, that being said, when it came to catastrophic recovery this particular OS/FS marriage made it virtually impossible for any third party standard file system handler, or tool, to recover lost, or deleted data. The following is an outline of one of the basic data structures, the Super Block, and how it differs from the standard UFS file system. These differences are the ‘fly in the ointment’ when it comes to using standard UFS data recovery tools. Read my article on SCO Unix RAID Data Recovery for more insight on the UFS. 

On-disk file system data structures are the key to data recovery. The knowledge of how a file system resides on the disk is the only way to recover from catastrophic data loss. Using on-disk data structures and their relationship with each other will help a recovery expert piece together lost data on a file system that will not mount. In essence, the data recovery technician creates a virtual file system using key data elements from the on-disk structure. These data elements go through a mathematical and geometrical scrutiny. This evaluation of the data must be strict enough to allow for corrupt data parsing, but flexible enough to build the file system from a partial data structure.   In other words, a sort of ‘artificial intelligence’ is used to compare, evaluate, and assign data values to key data elements through the use of file system structure placement.  A basic element of the file system in this particular case is the Super Block.

The Super Block is a broad spectrum definition of the entire file system.  Although not defining file placement, and block usage, the Super Block is the crux of on-disk data element placement that will lead the data recovery technician to file name, inode definition, and ultimately data block placement.   Data fields that reveal such values as total inodes, total data blocks, total cylinder groups, can be used to define a cohesive file system and in many cases rebuild a corrupted data structure.  The Super Block defines coarse data that can be used to calculate cylinder group definitions that inevitably lead to directory definitions, and a methodology to build a file tree.

The Super Block is defined across the disk in each cylinder group.  This fact alone can aide the trained data recovery technician in the alignment of the file system. Once aligned, it is a simple matter of back tracing directory name, inode definition, and data block in order to build a file tree. As an example the Super Block designates the primary inode block.   When parsing the first cylinder group inode 0, and 1 are undefined and the 128 byte data elements are zeroed.  However, inode 2 is defined, and can be traced to the root of the directory structure. Using recursion, one can easily define a full tree by using this single data element.

SNAP UFS File System Data Recovery

There are many more data elements that are an integral part of the SNAP UFS, however, the one basic element that is needed in order for third party UFS handlers to function is missing. Each on-disk data structure maintains an element that is unique to its particular type.  This element is defined as a ‘MAGIC NUMBER’. This magic number, however derived, is a tell tale element that can be used by the technician to find certain data structures. For whatever reason, SNAP decided to ignore the magic number and it is not stored on-disk. This may be an indication that the SNAP file system designers did not want to carry extra data elements that were superfluous to the functionality and definition of the file system. It is a good strategy for saving precious space in a ROM perhaps, but is not a sound strategy if one is trying to piece together a file system and has no idea where to start. I am not trying to second guess the SNAP Appliance designers, it is merely a fact of the on disk structure and must be dealt with.

If a software engineer wishes to design, code and implement a SNAP Appliance UFS recovery handler then the magic number must be taken into consideration. There are several other data elements of the super block structure that must have certain values. These values can be boundary tested, and used to find other data elements that have a more traditional on-disk data structure. In other words, if the super block cylinder group element points to a particular sector on the disk, that sector can be loaded and masked with a cylinder group on-disk structure. The structure can then be boundary tested and if the testing proves positive then the original super block placement may be correct. Of course, several other elements must be tested, but if the tests return in a positive manner, it is very likely that you may have found your super block without the use of a magic number.

In the final analysis it is up to the data recovery technician to evaluate each SNAP Appliance, and the possibility of recovery. However, with calculator in hand, and hex editor on screen, a well versed data recovery technician can find the super block, and in that, use that key to unlock his clients lot data.

If you have any questions pertaining to this article, or others I have wrote; please contact me at:

Dick Correa
DTI Data
Senior Systems Analyst / Senior Software Designer
dickc AT dtidata.com

---

SAN SNAP RAID Recovery is our main page or you can find out more information about data recovery.

RAID Server Hard Drive Recovery

DTI Data specializes in server hard drive recovery. In the past only large companies used RAID configurations for storage in their servers. Nowadays even home users have RAID setups in their personal computers, so small companies are also more likely to have RAID arrays in their servers.

RAID Hard Drive Recovery

When a server fails, especially when it has a RAID array, the situation is usually critical. A server is responsible for many things including, file sharing, backing up company data and even printing documents across the network. A true network set up has one or more servers and computers that are workstations and obtain files and applications from a primary machine.

A server that has multiple hard drives is using a RAID system for redundancy and expanded storage or performance. The best type of simple RAID is a RAID 5. This allows for expanded storage and performance, but also allows for redundancy. If one drive fails, the RAID array can still function, even though it is in a degraded state.

Once a hard drive in a RAID array fails, an engineer can do a hot swap and attempt to rebuild the array. This can be very dangerous because if there is a hiccup during the rebuild process the whole array can be shot. If DTI is called early on during the crises, we can often times help prevent hard drive recovery. 

In simple cases where there are under 10 active hard drives in the RAID array, there is a very good chance DTI can recover all the data. In a case where there are 3 hard disks and one of them have failed, DTI only requires the other 2 drives to restore files. Since a RAID 5 system has parity that runs across all the drives in most cases we don’t have to perform physical hard drive recovery on the damaged hard disk. In this type of a data recovery we perform a virtual recovery of the array.

When preparing your network it is a good idea to use the client - server model. Be sure to use at least a RAID 5 to configure your storage so you have redundancy and security from data loss. The best bet is to have multiple back up plans to protect your data and avoid hard drive recovery.

Novell NSS RAID Data Recovery

Novell NSS: Parsing the LEAF

About three years ago I received a RAID that had a Novell OS on it.  The RAID was close to 2 TB and consequently was sporting a very hefty NSS file system.  There were several problems with this recovery, but after several weeks of trial and error, and a little luck the client received their data, and we, in return, received our recovery fee.  The following is a summary of the steps taken for this recovery.  These steps not only cover the RAID recovery, but the file system recovery, and ultimately the clients recovered data.  The steps also offer something else, a method for parsing a file systems on disk structure.  In other words, how I systematically found the few data elements I needed within an NSS file record in order to recover the data. 

One last note before I get into the actual nuts and bolts of the recovery.  I am a 30 year ‘C’, Intel 80×86, Motorola 68000, and MOS 6502 assembler coder.  I have been a ‘bit fiddler’ for a long time, and I am used to getting down on the wires. The methods I describe are not for everybody, but I have used them over the years and have found them successful.

As a RAID recovery specialist you will find the following conversation the norm.

ME: What exactly happened to the array?

ADMIN: Well, not exactly sure, when I came in this morning it was down.

ME: I see.  What did you do to get the array back online?

ADMIN: Uh, I replaced the amber lit drive, I did a rebuild, and the rebuild froze.

ME: Did you make images of the disks before you tried the rebuild?

ADMIN: No. Why? Was I supposed to?

In all the years of data recovery, only one (1) admin had the wherewithal to make images of his disks before they did anything on the RAID.  If you are an admin reading this and your RAID degrades or goes down, follow these steps:

1. If it is not off, shut it off.  If management whines, (they always whine) ask them if the have the $26,000 it is going to cost to recover the array.

2. Don’t turn it back on. See step 1.

3. Find a nice piece of data imaging software (WinHex) and make images of all the drives that you can.  Some may be damaged, don’t worry about them; just make sure you image the good ones.

4. Don’t leave the bad ones in the array, they still may be recoverable and using them can, and will exacerbate the physical problem.

Now you that you have images you can do what you want.  If you can’t get the array back, at least the people you send it to will have the original starting point, and a better chance at your recovery.

Sorry about the RAID recovery 101 lesson, but it ties in with this recovery.  This exact thing happened. A drive went down, they rebooted, saw the amber light on one drive, replaced the drive, rebooted, started a rebuild, and the rebuild froze. However, the rebuild also used a drive that came back online ‘magically’ and the entire front of the array data was corrupted by a drive with stale data. I guess they should have made images.

At this juncture I now have a RAID with a stale drive embedded in the stripe in the beginning part of the array.  I have written some software that will tell me where the break point is in the corruption, and where the good data starts.  Once that was determined, I used another piece of generic RAID software for finding stale data to get the stale drive out.  Once I knew where the stale drive was I then built a virtual drive from the remaining drives and put that drive into the array. Phew!

The next step was to destripe the array onto a server, and then try and build the file system. I used another in-house tool to calculate the stripe, as well as verify the drive order.  Once that was done I destriped the array onto an in house server.

The final step was to try and mount the file system using NSS file reading and repairing software. I had some commercial software, as well as a piece of in-house software that I had been working on for reading NSS.  None of the commercial software would read the file system. My piece of half coded in house software also failed.  Not good.

So here I am, I have what appears to be a good destripe, but no way to build a corrupted files system.  The array is worth a good deal of money so the boss wants me to figure something out. I did have a few strikes against me but I had one big advantage.  The client was a sweetheart.  Very understanding, and willing to wait four to six weeks for the data. So, I cleared my schedule, told my boss if he wanted this array to leave me alone for six weeks,  and decided to buckle down and decipher the on-disk format. 

In my next installment, I will show you the steps I took to decipher the NSS record format.  Until then, back up your data!!!!

RAID Data Recovery Case Study - SCO Unix - 1

Data Recovery: A partnership for success

With close to 30 years of software design, programming, and implementation I have seen thousands of clients where their data has been, lost, drowned, burned, erased, deleted, and maliciously destroyed. In all of these cases where the data was successfully recovered there has existed a common thread. That being the client had an integral part of the recovery. Let me repeat that. The client and the technician had a quasi symbiotic relationship each, depending upon the other for the greater good.

That good being the client’s data restoration.

This being said, rather than throw a bunch of theories, hypothesis, and philosophies out for you to digest, lets look at a real case study in data recovery. I received a call from a doctor who had an old RAID 5 with four drives. The operating system was SCO UnixWare 7, and the file system was VxFS. The client related that the RAID had been sent out to another company but the file system it was too corrupt to be recovered. The company indicated they had worked on the RAID for over a week, but could not get the file system to align. They sent the array back to my client with their apologies, but not so apologetic that they didn’t keep the diagnostic fee which was substantial.

Since DTI does not charge a diagnostic fee our initial interrogation of a prospective client is extensive. We will not take any damaged media in that we feel would take too many man hours to recover, or parts would be so expensive that it would not be fiscally sound to attempt recovery. Pre recovery interrogation is actually a very important part of the data recovery process. One must understand that you are speaking to a client that is usually in an agitated state, bordering on hysteria.

They may be losing thousands of dollars every hour, and they have no real sense of how to get their business back on track. You are basically a life preserver in a sea of tribulation. As an interrogator you always keep in mind what is best for the client first and what is best for your company second. Ultimately, if you keep this philosophy the client will be happier, and will be much more cooperative when assisting you in recovering their data.

In the case of the doctor I already knew that someone had tried to recover the RAID and gave up. I also knew who the company was that had attempted the recovery and they were usually very thorough. I asked the doctor a few more questions as to how the RAID went offline, what had he done to try and recover it, what did he believe the original recovery company did, what state was the media in, etcetera, etcetera. DTI specializes in recovering data when others have failed. If you have sent your data somewhere else and your files were not recovered DTI can help.

After all the physical questions about the media I turned my questioning to the data to be recovered and what data was most important to the doctor. The doctor explained that he a third party piece of software that kept all of his patient data. This included billing, patient histories, procedures, and a great deal more. It was important, above all else that this database, and all related data be recovered and brought back online within the application. After a few more questions about his business, and this database I agreed to take the RAID in and attempt a recovery.

What made me decide to take this RAID was that I am very familiar with databases. I have designed several for very large corporations and even programmed some low level B-Tree handlers. I also had an idea what the data would look like, and how it would be laid out on the drive. The doctor was also very knowledgeable about this application and could help me with the recovery. As you can see, the recovery was not just about RAID, hard drives, operating systems, or file systems. It was about this doctor’s practice and how could I understand his patient base in order to locate his data and ultimately bring him back online.

The RAID arrived and the in-house software I wrote and used to view the array found exactly what the other company found. A corrupted file tree and inode structure in the beginning of the file system. There would have to be extensive eyes on disk data using a hex editor and calculator to try and piece together the superblock and inode structure. Even if that was accomplished there was no guarantee that the file name or the inode would be intact to recover the file system. My recovery strategy turned from trying to find the file names, to locating the raw data. In order to do this I had to understand the type of data, and its on-disk structure.

I searched the Internet looking for the file extender as a search parameter. That was of no use, the data was of a proprietary nature. I went to the website of the company looking for clues as to how the data was stored, there were some but not enough. I then took out my trusty hex editor WinHex and started cruising the destripe. After several hours I was rewarded with a block of sectors that looked like a database. I called the doctor and he and I discussed what the data looked like. He said that he knew which file that was, and it sure sounded like his data. At this point although I found the data block, there was still no way for me to break up the data into files.

There were over 30 flat files in this database, some were related to others and each had at least one index tied to it. I asked the doctor if he had any sample data he could send me to look at. He immediately sent me several files and said that these are the file types that must be recovered. So with a WinHex I looked at each file to determine if there were any unique markings that would distinguish the beginning of one file, and the end of another. After several more hours I found the key to these files. I called the doctor again, we discussed my findings. He then asked me how I would break the files up. I told him I would write a program specifically for his data that would filter out the file blocks and then save those blocks into several files. He asked for a time frame I gave him one and began coding.

The software scanned the entire array looking for beginning and ending signatures, once found it created a file and placed it in a folder. The software found over 300 file segments and the scan took 8 hours. Once again I contacted the doctor and told him this. This was the single most critical portion of this client’s recovery. I told the doctor that he was going to have to help me with looking at the data. He knew what was in the files, he knew what data belonged with what, and he was the only one that could piece the data together. He asked how he could do that. I said I would teach him how to use WinHex, show him how he could piece the files together, and then take those files and import them into his application.

At first he was a bit apprehensive, but I tried to make him feel at ease by saying I would be there to help him every step of the way. I also indicated that nobody knew his data like he did. He was a recovery expert when it came to his data and I was only a tool that he was using to get his data recovered. He agreed to help in his recovery and we became partners. I gave him my personal cell number so that he could reach me whenever he needed, night or day.

As a side note, he did call me once while I was on the golf course. I missed a putt, but hey, he was my client. Over the next few days we sent emails and spoke on the phone extensively. We became friends of a sort and worked together to get his database online. It was long, tedious, and at times fun to see this project grow. All in all I wrote three custom pieces of software, sent the doctor DVDs of his data, and learned a great deal about his application. At the end of it all we were successful. My client got all of his data back, his practice was brought back online, and in a very real sense I made a friend.

If this doctor, this friend, ever runs across a similar situation with either his business, or someone else, who do you think will come to mind first? Hopefully, it will be me, the guy who spent countless hours in the trenches with him, and together we brought his practice back online.

Data recovery is not only about dollars and cents. Its not just cold labs and mindless pieces of software. It’s about taking to heart somebody’s troubles. It’s about helping first and business second. With this philosophy, every recovery is a partnership, and a potential friendship waiting to bloom. It has proven successful for me in over thirty years working with clients.

Call Toll Free: 1-866-438-6932 or fill out an online quote form if you need data recovery.

RAID: What it is and how it works

Definition: RAID stands for Redundant Array of Independent (or Inexpensive) Disks. It involves the configuration (setting up) of two or more hard disk drives in combination for fault tolerance and performance. RAID disk drives originally were only used on servers in enterprise locations. Now with the advent of gaming and videos, RAID systems are found in home and office personal computers.

RAID is a method of creating one or more stores of data storage space from several hard drives. It can offer fault tolerance and higher throughput levels than a single hard drive or group of independent hard drives. You can build a RAID configuration with IDE (parallel ATA), SATA (Serial ATA) or SCSI hard disks. Dell is shipping computers pre-configured with RAID 0 arrays for high output gaming and video applications. The problem with RAID 0 is if one drives goes, that’s it! The data is lost. RAID 0 data recovery is the absolute toughest data recovery situation.

The exact meaning of RAID has been much debated and much argued. The use of “Redundant” is, in itself, a contentious point. That several manufacturers have deviated from accepted RAID terminology, created new levels of disk arrangements, called them RAID, and christened them with a number has not helped. There are even some single disk RAID configurations! Double parity, RAID 1.5, Matrix RAID etc., are examples of proprietary RAID configurations. One of the key players in NAS devices - SNAP has a very proprietary system of RAID. SNAP OS is also a unique operating system. While based on Free BSD, it is still a very complex recovery.

Data can be distributed across a RAID “array” using either hardware, software or a combination of the two. Hardware RAID is usually achieved either on-board on some server class motherboards or via an add-on card, using an ISA/PCI slot. Newer motherboards that use SATA technology have RAID controllers “on board”.

A RAID 0 (also known as a stripe set or striped volume) splits data evenly across two or more disks (striped) with no parity information for redundancy. It is important to note that RAID 0 was not one of the original RAID levels and provides zero data redundancy. RAID 0 is normally used to increase performance, although it can also be used as a way to create a small number of large virtual disks out of a large number of small physical ones.

A RAID 1 creates an exact copy (or mirror) of a set of data on two or more disks. This is useful when read performance or reliability are more important than data storage capacity. Such an array can only be as big as the smallest member disk. A classic RAID 1 mirrored pair contains two disks (see diagram), which increases reliability exponentially over a single disk. Since each member contains a complete copy of the data, and can be addressed independently, ordinary wear-and-tear reliability is raised by the power of the number of self-contained copies.

A RAID 5 uses block-level striping with parity data distributed across all member disks. RAID 5 has achieved popularity due to its low cost of redundancy. Generally, RAID 5 is implemented with hardware support for parity calculations. A minimum of 3 disks is generally required for a complete RAID 5 configuration (A RAID 5 two disk set is possible, but many implementations do not allow for this. In some implementations a degraded disk set can be made (3 disk set of which 2 are online). When it comes to RAID 5 Data Recovery, DTI only needs to recover 2 of the 3 drives (if it is a 3 disk set) to get the files back!

Many storage controllers allow RAID levels to be nested.

Common nested RAID levels:

RAID 01: A mirror of stripes
RAID 10: A stripe of mirrors
RAID 50: A stripe across dedicated parity RAID systems
RAID 51: A mirror striped set with distributed parity (some manufacturers label this as RAID 53)
RAID 100: A stripe of a stripe of mirrors

I saw a killer picture on the Internet of a water cooler explanation of RAID’s. I am unsure where it originated from or I would give them credit, but here it is:

« Previous Page