post

Tech Tip: “The type of filesystem is RAW” may not always signal disaster

This week, a client had a Windows server hard reboot (for no obvious reason) and when it came back their data volume wasn’t available.

The data partition was visible in “My Computer” and Disc Management, but it didn’t show free/used space and clicking on the drive letter resulted in an invitation to format the disc.

So there was a choice: restore from the most recent backup, or spend a bit of time seeing what we can recover. Whilst a set of guys started preparing the restore, I took the opportunity to have a bit of a play.

What we tried:

chkdsk d: /f

This is always worth a go, as it can fix all kinds of problems caused by not shutting down cleaning. In the case: No joy. “The type of the filesystem is RAW” and chkdsk gave up.

Mount using the Trinity Rescue Kit (http://www.trinityhome.org/

This bootable disc is a great resource and has been enormously helpful in the past. Generally speaking, this custom Linux distribution will try harder than normal to mount discs, will allow you to copy data from volumes with corruption, and much more.

On this occasion, TRK didn’t help. Although the Dell PERC was recognised after loading the MegaRAID driver (modprobe megaraid), and the partition showed up as /dev/sdb1, neither the NTFS or NTFS-3g tools would allow us to access the data on the volume.

What worked:

TestDisk. (http://www.cgsecurity.org/wiki/TestDisk)

I found this on Google and initially had doubts that it would help. After all, I had a valid partition, so I doubted its scanning capabilities would help here and, as expected, the partition scan didn’t reveal anything.

However, under the “advanced” features, there was an option to fix the NTFS Master File Table (MFT). It does this by identifying the backup copy of the MFT and using that the rebuild the master.

Quite why Windows doesn’t have tools (or, perhaps, doesn’t document them) to do this job is a mystery – after all, keeping a clone of the MFT is a function of the file system itself – but anyway TestDisk did the job perfectly.

What’s nice, is that attempting this is a fairly painless process; you can even take a backup of the allegedly faulty MFT before overwriting. It checked the master copy, looked to see if the backup was valid, then gave a simple option to replace the master with the backup.

Straight away, “My Computer” was able to see the volume correctly and, after a reboot (restarting the server service would probably have done the trick), all the shares became available. We took an extra backup (better to be safe than sorry) and the data was made available to the users.

Summary:

Obviously you can never guarantee that these things will work, and you really need to have proper backups, but this certainly saved the time and risk of data loss that a restore from tape would have cost.

Note: I subsequently learned that TestDisk was already on the TRK. Another reason to make use of this great tool.

Leave a Reply