In the previous two articles we have discussed how the RAID and some of the decisions the client made in trying to recover the RAID affected the PST file. In addition I discussed that there may have been a stale drive in the array and which probably caused the client to do something that normally destroys data to the point of where it can never be recovered. The client ran ‘chkdsk’, not a good idea for PST 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…
