The Mysterious Case of the Missing File System
Sometimes there is just no way to ascertain the events leading up to the loss of an entire file system index. The client may have no idea what happened. When looking at the file system as a whole there are no telltale markers left behind. So the only course of action is to analyze what you have and repair the anomalies. In retrospect it was an interesting exercise in data recovery, however, not knowing how it happened is still irritating.
DTI received a laptop from a client that had basically no data on it. I believe it was a total of forty-six (46) files. The file system was clean, the data that was available was good, and there seemed to be no damage to the hard drive. The client told us that he had thousands of files on the drive. His Quickbooks files as well as many other files pertaining to the running of his business were ‘magically’ gone one morning. He wanted us to find the files as well as making sure his laptop would boot again.
DTI has several in house tools that allow us to find certain file system markers on a drive. Objects like a Master Boot Record, the OS Boot Record, FAT32 Index, MFT Index, EXT2/3 Index, XFS Index as well as others. A trained technician with these tools can usually piece together a file system that is broken. However, this file system was not broken; it was intact and functioning properly within a Windows Operating System environment. With that being said, I set the tool to find all file system components in a RAW mode and just let me know what it found and where. Maybe if I could see the pieces of the puzzle they would lead me in the right direction.
I let the software scan for a bit and found that the MBR, the NTFS OS Boot Record, and MFT were exactly where they were supposed to be. I stopped the scan for a moment to look at the numbers and see if anything jumped out at me as irregular. Alas, everything was in order so I continued the scan. Further down the drive a second MFT showed up. This one had over 118,000 files in it compared to the 46 the other one had. It was in a place it had no business being in, but it was the right size and looked clean. I applied some math to the locations and did the following.
The NTFS Master File Table (MFT)
The standard MFT starting cluster for Microsoft Windows is 786432 (0xC0000), or 6291456 sectors from the NTFS OS Boot record. This is in fact where the first MFT resided. However, the second MFT was located at 804632 clusters, or 6437056 sectors from the same start point. It was interesting that the sector value was an exact amount of clusters from the start of the file system. It means to me that something had to put it there.
In addition, in the NTFS OS Boot record there is a value that references the start cluster of the MFT. In this particular instance the value was 786432. So what would happen if in fact I changed the MFT start point from 786432 clusters, to 804632 clusters? It was a simple matter of changing a value in the record and updating it. So, I did.
We rebooted the drive and low and behold the entire file system came back online. The odd thing was that the entire file system was compressed. We almost never see compressed file systems any more since the average size of a hard drive now is around 1terabyte. However, everything was there, and except for a few corrupt files the file system was fully intact.
We began to copy off the files when we started running into bad sectors on the drive. It made it impossible to copy many of the files off of the drive but we managed to get the majority off, including the Quickbooks file.
What did this all mean? We spoke to the client and asked why all of his files were compressed? He told us that it was good to have compressed files, and that coupled with defragging the file system everyday made the computer run faster. Then the light went on.
The client had a defragger that ran every night. The defragger that comes with the Windows Operating System will not move the MFT even if it is fragmented. However, there are some defraggers that will move them. What I think happened was in the process of moving the MFT the defragger ran into bad sectors and could not finish the move. Now you have an entire file system index moved and the NTFS OS Boot Record has no clue as to where it is. In addition there was a brand new MFT in the right place. I have no clue how that got there unless the client formatted the drive and didn’t tell us. So with the MFT moved, the new MFT in place, it looked like the client lost all of his files overnight, when really all that had happened was the index just got misplaced.
The great thing about this recovery was that it was done in place. No copying of files was necessary although we did it for safety sake. We changed a number and voila’ the files all came back. So the next time a client brings in a drive that has a similar circumstance, you could apply our solution.