Luckily for me that it was a network drive, only had one other file on it and had not be written to since the crash. If any data had been written to the drive after the fact the file disappeared, data recovery may have not been possible.

How I ended up fixing it was to use a hex editing piece of software (I happened to use Winhex, though there are others that would work as well) that allowed opening up the drive to view the raw data. I located the file that was already visible on the drive (the .stm file) to be sure I knew what the header looked like so as to not mistake it for the .edb I was looking for.

An Exchange Priv.edb file is made of pages exactly 4096 bytes in length, the header of the database is shadowed so there will be another 4096 bytes identical to the first right after it.

I located what I thought was the header of the Priv.edb and marked the beginning of it, then I counted down about 8 pages (around 32KB) and marked the end of the 8^th page and wrote it to a file (on a different drive of course!) called Priv-Temp.edb. At that point I was able to run eseutil /mh (dumping an exchange header) on my little temp .edb file. I could then verify that it was the correct Priv.edb file I was looking for based on the information provided by the header dump.

Then remembering that windows showed 140 GB in use and knowing the .stm file was only 60 GB, I counted down from the start of the header 80 GB and marked the end, and wrote that data to a file (on a different drive) called Priv.edb and copied over the existing Priv.stm. I used a calculator to make sure my file was perfectly divisible by 4096, it was not. I looked at the end of my new file and trimmed away the excess data I had grabbed so the file would be perfectly divisible by 4096 (the page size).

This was the first time I had done a recovery like this, so I was not very optimistic about it working. We tried to mount the database and SURE ENOUGH it mounted! Even if it had not mounted, other steps I could have taken would have been to run eseutil /p on my new data file, or I could have used other Exchange specific data recovery tools to extract the mailboxes from my created Priv.edb file.

Well, thank you for reading this, and once again if anyone has any questions you can email me at exchangesupport@dtidata.com

The video below shows 2 things of importance when looking at failed hard drives, the initialization process that lets the heads know when they are ready to start scanning the drive, and a drive with stuck heads. Newer hard drives have built in safety mechanisms that stop the heads from scanning the platters.

Learn more about hard drive recovery.

The video below shows the result of two very bad things that happened to a SATA hard drive. First off the connector was put in upside down, but then it was taken out and put in the right way. Both times, the chips on the PCB board got fried.

Every now and then the heads will impact on the platters and cause scratching. This is as bad as it gets as the scratches are eliminating ones and zeros. In the photo below, the scoring of the platters is on the very edge of the media. This cuses severe damage to the heads which have to travel over the edge of the platter at every read and write. Even if we replace the heads, the new ones will soon become damaged as well.

Hard Drive data Recovery Options

To learn more about your options when facing a clicking or grinding hard drive. Call us at 727-354-9665 or visit our hard drive data recovery page.

This won’t be an online advertisement for us, but a way for users who need our products and services to stay on top of the updates and feature changes to our line of data recovery software and freeware.

Hard Drives Are Magnetic Media

OK, so what does “magnetic media” mean? If you look at the graphic below it shows the different parts of a hard drive. The platters actually hold your data. They also hold a magnetic charge. The heads float over the platters on a buffer of air created by the spinning on the platters. The heads should never contact the platters since that will damage both the heads themselves as well as the data on the platters. Like the Earth, hard drive platters have a north and south pole. The relationship of where bits are stored according to the poles, determines if the bit contains a negative or positive charge. Each charge plus or minus reflects either a 1 or a 0, which can be translated into data.

Hard Drive Parts Laid Out

The motor spins up the drives to a certain RPM such as 7200, which is the most common rotaion per minute on modern hard drives. Once the platters are spinning at enough velocity to create the proper buffer of air, the heads will unlock and start to access the information on the hard drive. Information like the size of the drive can be sent to the BIOS and the computer can boot up.

Here is an up close look at the heads and actuator arm:

That being said, here are the steps to take when disaster hits and your Exchange server is not cooperating.

1. Make a backup of your important data, NOW!  Do not hold off on this step:
   1. For Exchange 5.5, you will want the Priv.edb, Pub.edb and Dir.edb at the very least.  For Exchange 2000 and 2003, grab the Priv.edb, Priv.stm, Pub.edb and Pub.stm.  For 2007, there is no longer an stm so just grab the Mailbox Database.edb and Public Folder Database.edb
   2. Grab any uncommitted log files.  I will explain later in this article on determining which log files have been committed and which have not.  You may also want to grab committed log files because if you need to go to an older backup of your database, these can be played back to bring the database up to date.
   3. By default the data files and log files are stored in the <exchange directory>\MDBDATA folder but can be split over 2 different drives.
   4. I highly recommend backing 2 separate backup copies of your data, at least one of which is stored on a completely different physical drive, computer or storage device.
2. While you are waiting for your data to copy, assess the situation and gather information:
   1. Find out what the problem is that is preventing Exchange to function by checking the application and system event logs.  Copy any events related to Exchange to a notepad document or write them down.
   2. Check for any other serious errors in the logs that could point to an issue possibly related (hard drive going bad, virus, etc…)
   3. Check to make sure there is enough hard drive space.  A hard drive filling up can corrupt your database if there is not enough room to grow it.
3. Gather information from ESEUTIL:
   1. Run ESEUTIL.exe /mh <path to data file>
      1. This will tell you if your file is in a Dirty or Clean Shutdown state
      2. It will also tell you which log files are needed to bring it to a Clean state on the “Log Required” line.
4. Resolve underlying issues first:
   1. If your problem is because of faulty hardware, inadequate drive space, a virus / malware, or something else external to Exchange, resolve that first.
5. Research the errors obtained during step 2:
   1. One of the best resources: Google it!  Searching for your error on Google can produce a wealth of useful information
   2. Also look on support.microsoft.com
6. Decide on a recovery strategy:
   1. Your options are:
      1. Recover yourself using Microsoft tools, 3^rd party software and online resources
      2. Restore from backup.
      3. Call a professional recovery company to assist.
7. For a corrupted database, here are the steps I would take to recover:
   1. See if ESEUTIL can solve the problem with a soft recovery
      1. Run ESEUTIL.exe /r E00 /d <path to database directory> /l <path to log file directory> /s <path to directory with checkpoint file> where E00 is the first 3 characters of your log files.
   2. Try to fix with ESEUTIL hard recovery
      1. I actually forego this step in most cases and only use it as a last resort as it CAN lose data from your database, but it can bring a database to a mountable state.  Use at your own risk!
      2. Run ESEUTIL /p <path to database file>
   3. Restore from a recent backup.
      1. If you have a recent backup, sometimes this may be a better option than trying to fix a corrupted database, because there is almost always some data loss when fixing a corrupted data file.
   4. Restore from an OLD backup and replay logs to bring current.
      1. If you have located an old backup AND you have ALL logs files from then until now, the log files can be replayed into it to bring it up to date.  If any logs are missing or corrupt, this may not be a viable option.
   5. Restore from 3^rd party software or call a professional.
      1. If all other recovery options fail, it may be time to enlist the help of outside sources.  Only you can put a value on what your data is worth to you and if it is feasible to hire (or purchase) outside help to restore your server back to normal.

Well that’s it for now.  This is NOT a comprehensive list, just  a few pointers that are often overlooked.  If you need any help with an Exchange issue, you can email exchangesupport@dtidata.com

What needs to be done is to separate the primary component of the RAID which is the hard drive from the controller in order to make a legitimate diagnosis. The following are some methods you can use that are isolated from a damaged RAID controller that will help you recover the data of your client.

First of all check the drives to make sure they are electronically sound. If you have SCSI drives use an Adaptec SCSI controller.  Perhaps an Adaptec 2930 would suit your needs.  They are inexpensive and have been around for a bit so all of the firmware bugs are worked out.  Put the SCSI card in a reliable computer and mount each drive individually. If the drives are SATA, or PATA use a standard interface port to mount the drives.

If the drive shows up in the ‘Disk Manager’  item of the ‘Computer Management’  then it is a pretty safe assumption that the interface is intact and you have some I/O between the drive and the controller. In addition to this DTI Data has a free surface scanner that will allow you to look at each drive and map any bad sectors on the drive.  If two or more drives come up having bad sectors then that could be the reason why the RAID went down.  RAID controllers are very sensitive to more than one drive exhibiting bad sectors or slow reads.  A RAID 5 controllers’ firmware may be fault tolerant, but when two drives have bad sectors the controller will degrade the array and bring it offline.

If, however, there are not any bad sectors on any of the drives then that is normally a controller problem.  You may have received a power spike, or some kind of memory fault but the fact of the matter is that barring those kinds of things the raid controller failed and will not mount your array.

In addition to doing a surface scan to verify if in fact you have had a raid controller failure you can check the integrity of the raid.  In a raid 5, the controller will do a set of mathematical operations on the data in order to be able to reverse engineer the data if a drive drops out of the array. These XOR math functions are used to do a rebuild on the array and take a degraded raid 5 hard drive and build it.  The drive will have to be replaced before the build but a raid 5 controller has the ability to integrate a brand new drive back into the array.

I bring up the raid 5 mathematics, because in order for the array to have a ‘clean bill of health’ the parity integrity must be intact.  If a raid card does not detect the fact that a drive has dropped out of the array then the drive will become stale.  A raid 5 will continue to function even if one drive is out of the array; however the raid card should notify the technician that the array has been degraded and the drive should be replaced and a rebuild performed.

DTI Data has a free diagnostic tool for raid 5 and will allow you to see if in fact there is a stale drive in the array.  I wrote a blog on how to detect a stale drive in the array and hopefully this will help you diagnose drive array controller failure.  If in fact the software finds a stale drive and the raid controller did not indicate that then the only way to recover the data is to create a virtual raid 5 array offline using software and images created from the raid 5 drives.

In order to create the images DTI Data has an inexpensive solution on our web site.  The software was designed and written with the technician imaging multiple drives to a single drive.  It is as easy as mounting the drives, selecting the source drives, the destination drive and then just walking away.  The software will not only image the drives but it will map all the bad sectors its finds and generate a comprehensive report.

These are just a few things that you can do to detect a raid controller failure.  DTI Data offers a set of comprehensive tools that will check all aspects of the raid 5 hard drive.  These tools are all on our website and will hopefully be an addition to your tool set.

If you need RAID Data Recovery Call Toll Free 1-866-438-6932 ext. 203 or direct 1-727-345-9665 ext. 203 to speak with a qualified RAID engineer now!

Question:

I have a 1TB Western Digital My book Hard drive. When I plug it in to either the USB or FireWire ports the computer detects and the instillation wizard pops up.
I follow the wizard steps and it says “successfully installed” but I cannot find my hard drive.
-My USB drives all work and I have other hard drives on the computer
-It says “you may safely remove hardware” in the task bar
-I’ve tried it on a different computer and had the same result

Answer:

So this gets a little tricky because just because “My Computer” isn’t seeing the drive it does not mean the computer is not seeing the drive. You would need to go to disk management and then see if it is reporting as a mass storage device in the machine. If it is then it is likely that the drives problem is a MBR (master boot record/partition record) problem that can easily be fixed with something like a remote recovery. The other option is to run data recovery software on it and you should be able to tree the hard drive, move the files off, repartition/reformat, and move the data back. If it is not being seen in disk management then it is likely a communication problem with the USB enclosure (box holding the hard drive) and the computer. Usually popping the enclosure open and then slaving it or putting it in a new enclosure fixes that problem.

Question:

I bought a Western Digital My Book Essential Edition 1TB External Hard Drive in July ‘09. I moved ALL my music, photos and personal files onto this hard drive. My CD-ROM drives quit working right before I got this….so I had not gotten around to “backing them up” on discs. STUPID-I KNOW!!!!
2 weeks ago it just quit working. I used it in the morning and in the afternoon, it wouldn’t work. It appears that it isn’t getting any (sufficient) power. It does not show up as an available drive when it’s plugged in.
Is there ANY POSSIBLE way for me to get my files off of this thing? I plan on sending it in to get it warranted-but I want to recover my files first.

Answer:

Ok, so like the above user he eludes to the face that it just isn’t showing up. it really could be all of the above fixes. My guess would be that if he wanted to get permission from Western Digital to pop open the enclosure he would be able to rule out the insufficient power problem. My guess would again be that the chassis has gone bad since this a very common problem. I always say that a My Book is a good product but only if you are going to plug it in just to back up and then leave it off most times. If you want an external device you can run all the time the best course of action would be to buy a high end USB enclosure and a hard drive in the size you want and build your own. This will give you the option to install fans in it as well as be sure it has good power to the hard drive. Heat is one of the major causes of hard drive recovery.

The fact of the matter is very rarely do I see only two drives go down simultaneously. I will see a single drive down, or all drives down, but almost never do two drives go down at the same time. Almost without exception one drive has failed before the second one has. In other words, one drive fails, the RAID card degrades the array and continues to provide service, then a second drive fails and the array goes offline. How does this happen?

There are several reasons. First of all, a RAID card will normally send a loud alarm that can be heard in the far reaches of the universe. In order for that alarm to work it has to be configured in the firmware, and the speaker has to be undamaged. Many times the alarm does work, however the technician does not want to take the array offline since there are several users who would burn his image in effigy if he did. So, he turns off the alarm and promises himself to replace the drive when he shuts down. That day never comes. If the array is software managed and not hardware managed then there is no alarm, however an email is usually sent to apprise the technician of the impending catastrophe he will experience if the drive is not replaced and a rebuild initiated. But! The email address that was used at configuration time 8 years ago is long gone, or, the spam filter set up by the same technician bounces the email that has the ominous warning. For whatever reason, the drive is left offline and the RAID continues to provide service.

Then a second drive goes offline and the entire array comes crashing down. Most technicians try several reboots, or forcing the drives online. Some will try a rebuild, and some will replace both drives and try to do a rebuild of the array with two new drives in the array. None of these work, and all will cause permanent data loss making recovery impossible. The best course of action for any array recovery is to take the drives that are still working and make images of them onto another hard drive. We have a very good piece of imaging software on the web site that will allow you to image multiple drives onto a single drive titled “Speed Clone for Windows”. If you have more than one drive in the array that is damaged then those drives need to be sent to a clean room for an image recovery, however, the majority of the time there is no damage to any of the hard drives in the array and the imaging software will act as a safeguard for any steps you take for a recovery.

With all of this being said a technician will still have the problem of a stale drive. If the stale drive can be isolated and the drives in the array are not damaged then the stale drive can be replaced with a new drive and a rebuild performed on the stale drive. So the challenge is, how does a technician find the stale drive? Using a simple hex editor which has a search routine any technician can find a stale drive. One note, this technique only works on the NTFS file system, but I am sure it can be adapted for other file systems as well.

NTFS uses a table for keeping track of the files stored on the drive. This table is called the Master File Table (MFT). Each file on a drive has one entry in the MFT. Each MFT entry houses a great deal of data pertinent to the file. The MFT keeps the dates of the file, security attributes, the file type, the file name, where the file is stored and many more items too numerous to mention. The MFT also has an internal attribute that is unique to the record. That attribute is called the MFT record ‘magic’ value. Each record has the same ‘magic’ value to allow the operating system to verify that it is processing an MFT record. This ‘magic’ value for the MFT is the four letters ‘FILE’. This value is located in the first four bytes of the MFT record. Knowing this, if we count every sector that has the ‘magic’ number located in the first four bytes we would get a very accurate idea of how many files are on this drive. In other words, by counting the magic numbers for the MFT, we can determine how many files reside on a drive. In addition to the magic number, the MFT is normally stored in one area, this can also help us find each MFT record. Now knowing that we can find every MFT record by using a search for the magic number how a RAID 5 stores data across the array becomes very important and I’ll explain why.

A RAID 5 stores data equally between all drives in an array. Using a four drive array as an example a 800 KB file will be stored across all four drives equally. In other words each drive in the array will receive 200 KB of the file. This fact does not hold true for smaller files due to the stripe size, however, for our purposes we are dealing with a very large file, the MFT. The average server will have between 250,000 and 500,000 files on the array. As an example let’s use 400,000 files to illustrate this point. If a four drive array has 400,000 files then each drive will have 100,000 MFT records. In other words, if we were to search each drive for the MFT ‘magic’ value we would find 100,000 entries per drive. Let’s take this scenario one step further. A drive drops out of the array with 400,000 files but continues in service. As the array is used more and more files are added to the array until a few weeks later the server now has 500,000 files on the array. If we do a search now for the MFT magic we will find 125,000 files on the three drives that have remained online, and only 100,000 files on the drive that dropped out of the array several weeks ago. As you can see it is an easy matter to determine that the stale drive in the array is the one with fewer MFT entries.

It must be noted that even though one drive has dropped out of the array it is still a four drive array. The drive that has dropped out of the array becomes virtual. In other words, there is no data written to the drive and all data read from the drive is calculated from the other three drives. For this reason a degraded RAID 5 will run slower since it is calculating the virtual drive on the fly.

This is example is somewhat simplified but the method is sound. I have written a scanner that does all of this automatically and will tell me which drive is the stale one. The software uses a much more enhanced MFT record filter and keeps track of the calculations real time. The software is also available from attending one of our training classes.

I hope this information has been of service to you. If you have any questions I will be more than happy to answer them on our blog which is updated daily or you can call me directly at 727-345-9665 ext 203.

NAS devices come with a very nice web like interface.  It allows you to configure your NAS device, set permissions, add users, setup stores, so on and so forth.  The interface keeps track of the health of your device and has a nice log file that you can print out and look at.  However, the underpinnings of a NAS device are meant for the Linux, and BSD gurus of the world who are familiar with terms like LDM, RAIDED LDM, XFS, XFSCK, and many others that would bake your skull.  With that being said if your NAS device hiccups there is no real way to get to the device other than the web interface.  On some devices there is an RS-232 port on the back of the device that allows you access to a Linux or BSD prompt by terminaling in.  I’m not sure what good that will do you considering the file system is probably hosed to the point where it will not mount, or the RAID is degraded so badly that it will take five men and a small boy to try and get it back online.  In other words, as long as nothing goes wrong,  the device is a dream.  BUT! The minute something happens you have no control over your data, and in this industry, it is not ‘IF’ you have a crash, its ‘WHEN’.

I have written several articles on SNAP devices, the file system and how to recover your data.  I have also worked on Falconstor which is the subject of this particular article.  The following is a recovery I did without using a recovery tool.  I used Linux and some tricks to fake out the operating system, and the XFS file system handler so it would mount this four drive RAID five array and allow me to transfer data through the network.

There are two types of databases.  Static, and virtual.  A static database is allocated before run time, and the size stays the same.  In addition, the record format is usually static as well.  Static basically meaning that all the sizes remain the same, and if you want to change a field size, of record size the database must be rebuilt.  I used to work in a UNIX database called UNIFY that had both options.  The upside to a static database is speed.  They are much easier to index and in many cases no index is needed.  Record placement in the file is used as indexes.  The down side is that if you want to change a record, or a field in a record you must make the change, export the data, and import the data back into the database.  You don’t see many static databases anymore if at all, but the database admin and designer really earned there money in the day when this type of database was used.

Another type of database is a ‘virtual’ database.  This database has record sizes that are virtual, field sizes that are virtual, and the database itself can grow as large as is allowable by the file system so it is also virtual.  The upside to this type of database is that you can make any changes you want to the records, fields, size,  data type, etcetera and you do not have to rebuild, or import the data.  A database change can be done live.  The downside is that you need indexes, and that can cause design issues.  Maintenance on the indexes can slow drive access.  There is one issue that came to light for the old PST file format which is a virtual database using static data types.  Some of the data types used to access offsets in a PST file were INTS which have a maximum value of 2147483647.  If this value is translated into bytes then this is 2 GB.  Coincidentally, the PST files in Office 2002 and before would corrupt data in files 2 GB or larger.

Why all this talk about virtual and static databases?  NTFS 5.0 is virtual.  The MFT is virtual, and all file and folder allocation is virtual.  The problem with this virtuality is that the main component of a MFT is not virtual.  A Master File Table Record is not virtual, it is static.  It does not exceed the size of 1024 bytes.  That being said, what happens when an attribute of an MFT record exceeds the 1024 byte limit?  What happens when a file is so fragmented the a run list grows so large that it outgrows the MFT record?

Microsoft uses a facility called an attribute list.  In my next installment I will explain the attribute list and how it plays a starring role in the PST recovery.

We have learned about RAID rebuilding theory. Stale drives in a RAID 5.  We have covered NTFS 5 and some of its design components.  We have even looked at database design and how it plays a part in the recovery of a data file.  Finally, we covered static and virtual database sets, and what to do when they are mixed.  Now I bring you the attribute list.

As I stated before, the MFT has a static size of 1024 bytes.  It contains all the information about a file INCLUDING the runlist.  The runlist is the cluster map of a file and can grow very quickly.  One of the things that can cause a runlist to grow is file fragmentation, and when talking about a PST file, fragmentation is the byword.

When a runlist exceeds the confines of an MFT 1024 byte storage limit Microsoft implements a method called an attribute list.  To put it as simply as possible, an attribute list is another MFT record that houses ONLY ONE attribute type.  In other words, the runlist that was stored in the primary MFT record is now moved to another MFT record that is only used to store the runlist of primary record.  The runlist is exactly the same as if it were being stored in the primary record, it is just stored in another area of the Master File Table.  The MFT record is EXTENDED by using the attribute list.

There are two components of an attribute list.  An attribute type, and the data related to that attribute type.  The attribute type is maintained in a data structure called an attribute header.  The attribute header has several components, but the attribute type is a flag to tell the file system handler how to process the following data.  In this case we have a data type of 0×80 and a data storage type of non-resident.  These two attributes mean that we have a data runlist and should process the next set of data accordingly.

The attribute type also has another value which can be -1.  This value means do not process the following data and continue to the next attribute type. Now here is where it gets very interesting.

When deleting a set of data Microsoft has ALWAYS left the actual data behind.  In the FAT file system the File Allocation Table may have been updated but the File Entry Record was only ‘flagged’ as deleted.  A value is placed in the first byte of the record to indicate to the record is no longer in use, and in fact, this space can be used. This is called a ‘virtual’ delete and has been used in databases for years.  In NTFS, a flag is also set in the MFT but all of the record data is intact, just one bit in a flag is changed.

With this knowledge I will explain what happened to the PST file and how I used these virtual flags to recover my clients PST file.

Well, if you have stuck with me this far then you have made it to the end.   Just to recap, we have a PST file that has a file size of zero, and cannot be recovered.  We had a RAID with a stale drive that marked the file system as dirty and caused a chkdsk to be executed.  We have an NTFS file system that uses virtual flags to mark data as active and inactive in a database type environment.  Lastly, it is important to note that marking data as virtually inactive leaves the data intact.  Until something writes over the cluster where the data is stored, the data is not deleted, wiped, or otherwise changed.  It remains intact.

The final ingredient to this recovery is the fact that the file was so fragmented that an attribute list had to be used.  By storing the attribute list as an extension of the original MFT record it has a data type flag.  By changing the flag from a 0×8000, to a 0xFFFF the data is marked as inactive and not to be used by the MFT to find the runlist for our PST file.

So here is the secret to how I recovered this PST file.

The original PST record had index pointers to the MFT records that contained the attribute list data.  When the client did the rebuild he used a different drive and this data was not touched.  After the rebuild with the stale drive chkdsk ran and marked the file with zero bytes, and flagged the attribute lists type with 0xFFFF.  Now, knowing where the attribute lists were stored, and how the flags were set I executed the following steps.

First I took my hex editor and changed the file size to the original file size.  I use the size of the cluster map to find the original size.  Second I copied the original pointers to the attribute lists into the new MFT record.  Third, I changed the attribute type flags from 0xFFFF, to 0×08000.  This told the file system handler that the attribute list was now active again and could be used to retrieve the data. Fourth, I used a modified Recovery It All 2008 to move the PST file onto my server.  Coincidentally, the file was almost two GB in size. Finally, I used scanpst to cleanup any bad records in the PST.  During the rebuild some data got moved and overwritten but 95 percent of the file was recovered.

This was an excellent exercise and I really enjoyed this recovery.  I hope you learned something, I know I sure did. Take care, and as always…

Learn more about RAID 5 data recovery here.

Q: Yesterday I was cleaning out the rubbish from my PC, as it was getting a bit slow. Along the way I deleted an old user account folder from Documents and settings on my C drive.
Later that day I went to check my emails only to find my PST file was missing. at which point I remembered it was in the old user folder. I started looking for software to recover this file. The file is about 1GB and has lots of info that I need.

A: Their are a a bunch of schools of thought on this recovery method but generally they are all just that THOUGHT. You have to take into account a ton of different variables. The first being how much data was applied to the drive after he deleted the PST file. My guess would be a lot since he eludes to the fact the drive was full in the post. If the drive was being written to at all recovery options are dropped DRASTICALLY since the data is more then likely gone due to an over write. If there was no data put on the disk after he deleted it, then the best course of action would of course be an piece of software that could UNDELETE the file. As a last ditch effort I would sometimes recommend that the customer try some for of raw file harvesting but the drive will have to been defragged on a regular basis other wise the file will be all over the hard drive and the harvester will not be able to locate all of the pieces.

Q: I got an old Dell Dimension 3000 laying in pieces on my hardwood floor… and I can get other hard drives to read in it, even get an operating system to boot, and such. No issues.. But when I try to put this… Seagate Barracuda 7200.9
160GB hard drive in, it will not detect it, at all. Pulled up the bios, planning on inputting everything manually into it… But I can’t seem to find the option to do it… I can change the “Master drive” from … “Auto” to “Off” and that’s it.
I’m curious if there’s a way to know if the bios is compatible with this hard drive… if there’s a way to find out if it is, or isn’t.. Or just something I’m completely lacking intelligence on figuring this thing out. Seriously need this computer up with this hard drive. I can still access the drive from my computer… But I’m worried that if the HD Is infected.. IF it would infect my other HD’s… and I don’t want that to happen. I currently run No anti virus. I tend to avoid virus’s pretty easily, and very rarely actually get hit with them. and when I do, it’s usually pretty simple for me to remove them because I catch them pretty instantly..

A: So here is the deal this is a boot drive from another computer, slaving it into the machine COULD be causing some kind of “which drive should boot” conflict. The second problem he could have is that the bios is too old to see the drive, that it doesn’t support LBA mode or something strange like that. My personal recommendation would be to pull the drive out and get yourself a USB enclosure this will take all of those other issues out of the equation and then you can just deal with the OS seeing it which will make things much easier. It is a trick we use as a data recovery company when either Windows is having trouble booting with a certain drive in it or when we can not get the bios to see a drive.

OK, so I was really wanting a dual monitor stand for my two LCD flat panel monitors, mainly to get them up off the desk more to give myself more desk space and to raise them up higher.  The cheapest I could find one for was around $80.00, so I decided to attempt to build my own.  I did a little research and saw how other people were building theirs and came up with my own design (based on the size of the LCD’s, the height I wanted them and distance, angle, etc…)  I am SURE there are much better ways of doing this, but I wanted to keep it rather inexpensive.  Total cost of all parts came to around $25.00, give or take a few dollars.

Design:

1. First come up with a design.  Measure your two monitors and find out the length of pipe you will need.
2. Here is a scan of my original design:



Parts:

3. I chose to build it out of Galvanized plumbing pipe.  I used ¾” for the base and used a reducing coupling to make it ½” for the rest.  I also decided to use a 45 Degree elbow to have the monitors at an angle to each other.  The LCD mounts I cut out of plywood scraps.
4. Here are the parts I used:



Assembly:

5. Putting it together:



6. After painting it black:



7. Mounted to desk:



8. Make sure you have mounting hole measurements correct on the LCD mounts.  I had to go back and redo several times because I had measured the holes to be exactly 4” apart and it turns out they are not exactly 4” apart.  Also getting the correct machine screws gave me a problem.  #8 – 32 screws appeared to be the right size, but it turned out I needed metric size 4mm for the back of the monitors.
9. Mounting first monitor:



10. Finished!

DTI Data Recovery continues its excellence in software development by releasing Speed Clone for Windows. The new Speed Clone download package includes the Windows version as well as a bootable DOS ISO for cloning hard drives that are registered in the BIOS. It also has the original Speed Clone that works off of a floppy.

Speed Clone is a powerful tool that allows technicians to clone from physical to physical drive or create an image file of a physical drive. The most powerful feature of the software is the error reporting facility.  Using native Windows diagnostics as well as the internals of the software the technician can get a clear idea of the physical status of the drive.  By using a simple file system map a technician can accurately pinpoint problems in the file system. This software was designed with the knowledge that there may be bad sectors on a drive and that is the reason it is being cloned/imaged. In order to facilitate an accurate diagnosis a robust error reporting system has been integrated into the software.  This fact alone will make Speed Clone a technicians most valuable tool.

In addition, Speed Clone will allow the technician to walk away from a multi-drive multi-image session instead of watching for each image to finish.  This time saving function will allow for easier replication of RAID components before a destripe or RAID mount is attempted.

Even if the technician is not cloning the ‘Scan’ facility allows you to take a diagnostic look at a hard drive.  With the printable error report this tool can be used to advise a potential client of the possibility of recovery.

When working with hard drives a technician rarely sees one that is not damaged.  Speed Clone was designed with the technician in mind to help give them a leg up in this competitive market.  Add this software to your arsenal of data recovery tools in order to better and more accurately serve your clients.

If you work on hard drives you cannot be without the full suite of Speed Clone!

Purchase Speed Clone here or read more about it on our Speed Clone page.

Only $49.50

Bad sectors on a drive are very hard to diagnose as they look like so many other problems and can be masked very easily.  One minute the drive is working and the next it is not.  This usually sends a technician into a flurry of questions as to what new software has been loaded, what websites have been visited, is the virus and malware software up to date, and on and on.  Ultimately there is really only one way to check the drive for bad sectors and that is with software.

DTI Data offers this tool to all who think they may have bad sectors.  We send it to everyone who we believe may have bad sectors to help us diagnose their problem and to give them a proper and accurate quote.  We try our best not to quote using some sort of arbitrary cost spread.  When a person is getting ready to spend a large sum of money they want the amount to be as accurate as possible.  DTI Data works closely with the prospective client to offer the best value for their dollar in addition to helping them accurately assess their data recovery situation.

One final note, while running the software if there are several bad sectors and it is taking a very long time to scan the drive then it is advisable to stop the scan.  Never brute force a drive scan as it can cause more damage to an already tenuous situation.

Download The Freeware Utility – Windows Surface Scanner here.

Thirty years ago the Internet was a fledgling set of 2400 baud modems and the communications monster Compuserve.  Compuserve had ‘Mega Wars’ and a small library of source code that could help a programmer.  However if an indie developer wanted to use the full power of a PC it was the book store and the myriad of technical masterpieces that would enable me to turn a PC into a computing dynamo. One of the first books I purchased and still have to this day was ‘The Programmer’s PC Sourcebook’.  This book had every BIOS interrupt and all the different flavors of the interrupt.  It had thorough descriptions of the DOS interrupt architecture and how it could be accessed and in many cases used to adapt the operating system to your own design.  The book is a marvel and there were many a time that I would just sit and thumb through its pages reading it like a good fiction.  Times were simpler then, you had to understand the hardware, the underpinnings of the operating system, and the ins and outs of how it all worked together, but it was much cleaner back then.  When you programmed on the wires there was an almost reverent symbiosis between the coder and the platform.  It’s hard to describe but I miss those days.  I suppose I am a purist at heart.

Anyway, I digress.  This book, ‘The Programmer’s PC Sourcebook’, other than being one of the best technical reference manuals in print was one other thing. It was HUGE!  I don’t mean it had a lot of pages, which it did, but the size of the book is like 18″ x 14″. It wouldn’t fit on a normal book shelf; I had to leave it on my desk all the time! It was also a paperback that I used daily for years. All of that being said what does that lead to?  Eventually, the book started to fall apart. Pages would fall out, and soon it was just a stack of pages on my desk.  After awhile I lost the index to the entire book and that made using it almost impossible.  If I had to look up something I would have to thumb through the entire book and try to find the information.  After awhile I started my own index which I kept on the side for the most used sets of information.  If I had only made a copy of the index on some copying machine I could have used the book more, but I didn’t and mores the pity.

After my sad book story, I suppose you are now scratching your head wondering, how does this have anything to do with data recovery from NTFS.  Well, you can stop scratching your head because here is the explanation.

A file system, any file system, is broken up into two categories, the index, and the data.  A file system is no different than a database.  A file system is no different than a reference book and its index. You have the data, and you have an index. In the NTFS file system you have the data which is stored in clusters, and you have an index called the Master File Table (MFT).  With this being the case, what if there was a way to save the index (MFT) in case something happened to it?  ‘What could possibly happen to my index (MFT)?  You could accidentally format your hard drive; people do it all the time.  A full restore could be done from either your restore cd or from the restore partition on your DELL, or HP, or whoever else has a restore facility and wipe out your entire file system.  Bad sectors could develop in your index (MFT) and the file system can become corrupt.  A virus can destroy an entire index (MFT) in the blink of an eye.  There are other ways but I am sure you get the picture. With all of these chances of your index (MFT) being destroyed isn’t it prudent to save your index?  I should have made a copy of the index to my favorite technical manual before I lost it.  Shouldn’t there be a way to save your NTFS file system index (MFT)?  Well there is.

I have developed a piece of software that will take your index (MFT) and save it to our servers in Florida.  It is extremely easy to use and allows you to save one (1) volume index onto our servers.  In the event that you run into a catastrophic situation and lose your index, you may have a chance of recovering a large portion of your data if you have saved your index to our servers.

A word of caution.  This is NOT a backup program; this is a way to backup the index of your NTFS file system.  Just like a book, if I backup the index of a book using a copy machine, but the book is destroyed in a fire, the copied index of the book does me no good.  However, if I make a copy of the index of my book, and lose the index, I can use the backup index to look up my data.  Finally, when you save new data to your file system the MFT is updated and changed to reflect the new data on your drive.  In the same manner an index from an older version of a book will not work on a newer version of the book.  So, if you save a lot of new data to your hard drive, it would be a good idea to backup your index again.  Once again, this is not a backup program, just a way to backup your MFT.

This may not be the total answer, but it is another option in the war to keep our data safe.  The more chances you give yourself for recovering your data, the better off you will be. Remember, it is not if it will happen to you, but when…

Download MFT Save Here

For more information about MFT Save Remote Restore Point for NTFS

For 1 month only, DTI Data Recovery is opening this course up to the public. We are offering only 4 online data recovery courses in 2009. Each course will include our full version data recovery software we sell, but also tools that only our engineers use. You will be able to recover everything from lost emails to deleted pictures, data lost from partition corruption and viruses as well as the following:

• Calculating and fixing a partition record for single and multipe partitions
• Restoring a deleted file by hand in FAT32
• Restoring a deleted file by hand in NTFS
• Determining the drive order of a RAID 5
• Restoring a file system using the backup OS Boot Records (NTFS and FAT32)
• Rebuilding a EXTFS2/3 file system using the super block
• Mounting the XFS file system from a NAS device in Linux
• Recovering JPEG files using a file harvesting technique
• Recovering MP3 files using a file harvesting technique
• Recovering a PST file using file harvesting, unused cluster map and scanpst
• Restoring the MFT from the backup
• Reading the block map for an EXTFS2/3 file system.
• Determining Block size of a RAID 5
• Determining RAID data set for a Simpletech NAS device
• Novell NWFS file system
• Microsoft Access Database file format and recovery
• How to configure a Knoppix disk
• How to configure a Bart PE disk
• Recovering data from a DBX file
• Swapping USB Enclosures

The course is discounted from its original price of $2500.00 to $995.00 and will not be held again this year.

Reserve your class now, before it is too late, only 10 members per class!
Call 866-418-3843 or fill out Online Data Recovery Training Sign Up Form

Learn more about online data recovery training here.

In order to understand how this happened an explanation of how the NTFS file system work, as well as a quick lesson in database design and management.  First the database.

The NTFS file system, well in fact any file system is nothing more than a real time database.  The records are stored as a flat file (Master File Table) and there are indexes (INDX Records) that have pointers into the flat file for fast specified data set access.  As an example, when you click on a folder in explorer and all the files are displayed the file system handler does not query the MFT and build a record set for that particular folder.  Each folder has its own unique record number.  As in any good relational database, each folder and file in the parent folder not only has its own unique record number but they also have a parent record number that groups the folder together.  Now, if the MFT were sorted by record number then  a binary search could be used to find the parent folder, build the list, and then pass the list to the GUI for display to the end user. However, as I said before, the MFT is a flat file that new records are appended to and is never sorted.

One of the reasons the MFT is not sorted is because before NTFS 5 there were not any embedded record numbers in the MFT.  The record number was assigned by the placement of the record in the file.  In other words, the first record in the file had a record number of zero, the next record was one and so on and so forth.  This was a very poor design in respect to data recovery.  If the MFT became fragmented, and the cluster map for the MFT was destroyed (Record zero), then there was no way to reconstruct the MFT since a fragmented file has no order to it.  However, NTFS 5 fixed all that by embedding a record number into the MFT record.

All this being said, the NTFS file system uses INDX records that keep a sort of short list of a folder set.  Just some basic information like dates, file size, file name, and some security.  This keeps the record small since the INDX record IS sorted and is kept sorted by the file system.  In other words you have a sub data set of records for display purposes only in order to offer a faster refresh of the data set in the GUI.  In addition, chkdsk will synchronize the MFT record, with the INDX record using the MFT as the base.

Well, seems like I have rambled on a bit here.  As I mentioned there are flags that are set in order to let the file system handler know when data is active and inactive.  In the next installment I will explain how this ‘flagging’ design used in a ‘virtual’ file system saved the PST file for my client.

Until next time…

Data Recovery

Chkdsk.  Say it loud and say it proud.  Chkdsk.  Kind of rolls off the tongue when you say it doesn’t it? One more time.  Chkdsk.  So there is no misunderstanding, chkdsk works EXACTLY AS ADVERTISED.  Chkdsk is not designed to do DATA RECOVERY! Chkdsk is designed to align a file system so that the Windows operating system can read it.  However, in doing so an end user can lose their entire file system.

Chkdsk will run when a volume is considered dirty.  Dirty can be defined as file size not matching the cluster map.  Cross linked files. An INDX record not having a matching MFT record.  Any file not having a parent folder (Orphaned).  The cluster map for the entire volume not matching what is actually allocated. Bad sectors within a cluster.  With that being said seeing this message “The file or directory filename is corrupt and unreadable. Please run the Chkdsk utility.” means that you probably have at least one of the situations I have mentioned.

As an aside, there are other methods for checking the file system to see if it is dirty before chkdsk is run. FSUTIL and CHKNTFS are two other command line utilities that can manage the file system without the use of chkdsk.   Some of the command line parameters for FSUTIL and CHKNTFS will be discussed in other articles.

With all this being said it was pre-ordained that the RAID with a stale drive would be flagged as dirty and therefore a chkdsk would be scheduled.  Since chkdsk is defaulted to run automatically it ran on this RAID and caused a great deal of damage.  Although many of the files were recovered, the PST file had been reset in such a way as the file system handler would not read the file.

Next time I will discuss what chkdsk did, how it affected the PST file, and in doing so saved the data.

Until next time…

Now that we have a basic idea of the RAID situation how do we solve the problem of a data set that is spread across more drives in the array.  One last note, I believe there was a stale drive in the array so that made it even more complicated to build a data set that would get this particular PST file off.

The situation with this particular file was that it was fragmented very badly.  This in itself is not a terrible thing but file fragmentation slows access and is very difficult to recover from if the file is deleted.  As I had mentioned before ‘chkdsk’ had been run on this drive, and in addition, the drive had a file size of zero.

In order to understand file fragmentation it is important to understand the NTFS file system.  I’m not saying you have to be a guru, however, how the file system stores the cluster map is of paramount importance in this recovery.  The following is a brief description of how the cluster map is stored in the NTFS file system.

All files and folders in the NTFS file system have a single record that houses all its information.  Attributes like the file name, file size, security parameters, the date of creation, updates, and much more is stored in a 1024 byte record in a database called the Master File Table (MFT).  The MFT is the heart of the NTFS file system and if destroyed will cause all data to be lost.  One of the attributes that is stored in the MFT is the cluster map.  This map houses all the information as to where the file is stored.  NTFS uses a storage unit called clusters to store data on the hard drive.  Each cluster is normally 4096 bytes (8 sectors).

The cluster map is extremely simple in concept but in application is horrific.  Basically it consists of two numbers.  The first number is the starting cluster, the second is the number of contiguous clusters from the starting cluster.  This is an extremely simplified explanation, but it is basically correct.  This cluster mapping is called a runlist.

Now, if a file is fragmented you have many of these cluster mapping pairs.  In fact there are files that have so many cluster mapping pairs that the cluster data must be stored in another record. In other words, the runlist must be stored in a second, third, or more records.  NTFS has a facility for doing this called an attribute list.  As briefly as possible, if an attribute grows so large that it cannot be stored in the main MFT record then an attribute list is built and the runlist is stored there.  The file that I had to recover had two extra records that stored an enormous runlist.

Next time I will explain how the fact that the file I had to recover was fragmented actually made the recovery much easier.  Until next time…

As fate would have it I received a three drive RAID 5 that had some serious problems.  Two of the drives had gone down and the array was now degraded to the point of not mounting.  I have been in this business for quite some time and I can tell you that I can count on one hand how many times two drives in a RAID 5 have gone down at EXACTLY the same time.  It is just a very rare occurrence.  However, I wish I had a nickel for every time two drives go down in a RAID 5 and one of the drives has been offline for an extended period of time.  In other words, one drive went down and either was ignored, or the RAID was configured to NOT send a warning, or the RAID card was defective and did not send the proper warning,.  In any event, I think you get the picture. Whatever the reason, one drive is down longer than the other drive and creates a ’stale data  ’state .  I believe this is what happened to this array.

In order to bring the array back online, the client forced the two drives back online, and then tried to mount the array.  The array goes from a degraded state to an online state.  The clouds part, the birds sing and all is right with the world. Almost.  Upon booting the array into the file system ‘chkdsk’ was automatically run.  Microsoft’s way of aligning the file system so that it to can be mounted.  However, ‘chkdsk’ shows no mercy.  Bad MFT record here, a bad INDX record there, a few misplaced INODES here and voila!  No more files.  You have a nice clean file system, with no data.  Not good.  In this case however, it was not that bad, the data was still basically intact, it had just a few anomalies.  I love that word anomaly.  I use it every time I am clueless as to what is going on. In addition to chkdsk being run one of the drives was still bad in the array, so the client swapped it out and began a rebuild.  After all this, the file system still mounted and ran for about another week.  Some users were complaining that files were missing or corrupt.  Whole folders were missing, so on and so forth, but basically, everything was cool.

Then something wonderful happened.  Another drive went out of the array, and now nothing would mount.  No array, no file system, no data, just quiet, kinda like a graveyard.  That’s when I got a call.  After hearing this story I almost bypassed the recovery because I KNEW it was going to be a headache, however, my technicians curiosity got the better of me and the client sent the array.  After some massaging, and tickling I got a great deal of the data back, however there was still this one pesky PST file that their entire business hinged on, and if I could get that back , well, the ebb and flow of the Atlantic tides, the drift of the continents, the very position of the sun along its ecliptic would align and all would be right with the world.

Next time I will describe the painstaking way in which I created the de-stripes used to recover the array, as well as a little help from some diagnostics in DTI Data’s Recover It All product.  Until next time.

The <NAME OF FILESYSTEM> Boot Sector is its official name and is the sector that holds the information on where the master file table or the FAT start on the drive. It also tells us important information like how big this particular partition is and where this partition starts. The really awesome part of the boot sector is that it keeps a back up of itself. The backup can be found at the end of the partition.

Ok so here is a boot sector, we can tell it is the boot sector because it of the NTFS in the upper left and side of the text side of my hex editor. When using a Hex editor/viewer it is also a good idea to make sure you have the 55 AA in the lower right hand corner of the HEX. Most HEX editor have a way for you to Apply and template to a boot sector so that you can view it as something you can understand and change.

This is the boot sector in a more readable format. You can see the important notes like the file system, hidden sectors (often call the offset). You can see the total sectors which gives us the total size of this particular partition if we take that number and divide it by 2097852 (which is how many sectors in 1 gigabyte). Also see that it has the starting MFT cluster, which is important because this is where the MFT starts. We can figure out where that is on the hard drive by taking that number and x by the sectors per cluster and then adding the offset. When I try to explain the boot sector to customers I use the analogy of  a car the MBR is the key that starts everything off but the boot sector is the like the engine it gets you where your going and does all the heavy lifting. I can usually repair a boot sector even when the backup boot sector have been lost with our remote data recovery service. If your hard drive is clicking or not seen by anything, you need hard drive recovery.

Call Toll Free: 1-866-438-6932 if you need help!

Now there are thousands of results when you type “data recovery” or “hard drive recovery” into Google or Yahoo. The question is how do you technicians or consumers know who to choose. Since those of you reading this blog know for sire we are serious, have lots of proof about who we are and are one of only 7 companies in the US authorized by major hard drive manufacturers to even open their drives! That last statement needs a quick clarification. Since Seagate purchased Maxtor, which had purchased Quantum, and Hitachi purchased IBM hard drive division, there are really only a few manufacturers that even make hard drives now. Out of all those hard drive companies, only Western Digital actually lists these authorized companies on their website. Click here to see DTIData on that list! To verify that you are dealing with a legitimate data recovery company, you may not want to stray from the WD list of partners!

This is something we have talked about for a long time. I wrote an article in January of 2008 called Data Recovery Truth and Consequences that is referred to by PC World magazine here (I don’t mind that Dick Correa got credit for being the author, this blog wouldn’t appeal to most of you without his technical articles : )

Even stronger than this is Dave Mohyla, our CEO, who wrote a whitepaper about the decline of standards in the data recovery industry. He wrote this article in 2004!

When looking for a data recovery company, it is important to know who you are dealing with as well as to check them out in the Better Business Bureau. Here is a link to the DTIData BB rank, an A PLUS! We strive to give our clients the best in software and support. We are the one of the only company in the world that fully supports its freeware data recovery software as well as our paid programs. We offer 24 hour support on all hard drive recovery and any customer can access the status of their case with our Drive Tracker system. Feel free to call us at 1-866-438-6932 anytime if you have questions about hard drive recovery.