When is it appropriate to run chkdsk?

A UPS failed and a Hyper-V box hosting 6 VMs went down (all Windows Server 2008 R2 x64, if it matters). When I booted back up, it did not automatically perform a chkdsk (which I have seen in the past). I didn't notice whether any of the VMs did chkdsk as they came back up.

In this situation, is it appropriate to:

  • Schedule a chkdsk on C:\ of the VM host upon reboot?
  • Schedule a chkdsk on C:\ of each of the VMs?
  • All of the above?

Or should I only do it when Windows recommends it and does it on its own during bootup? How does windows "know" when it's appropriate to do this?

TL;DR: If a VM Host goes down, do I run chkdsk on it and all the VMs or just let windows do that if it feels it's necessary?


Solution 1:

It's appropriate if you feel it is. For an important server, running chkdsk is a good policy. Balance that against the downtime you'll go through.

Microsoft believes it is unnecessary.

Windows Server 2008 no longer performs chkdsk after power failures due to "Self-healing NTFS" and "Transaction NTFS". From the wikipedia articles on Server 2008 and Transactional NTFS:

Self-healing NTFS
In Windows versions prior to Windows Vista, if the operating system detected corruption in the file system of an NTFS volume, it marked the volume "dirty"; to correct errors on the volume, it had to be taken offline. With self-healing NTFS, an NTFS worker thread is spawned in the background which performs a localized fix-up of damaged data structures, with only the corrupted files/folders remaining unavailable without locking out the entire volume and needing the server to be taken down. The operating system now features S.M.A.R.T. detection techniques to help determine when a hard disk may fail.

Transactional NTFS
A component of Windows Vista and later operating systems. It brings the concept of atomic transactions to the NTFS file system, allowing Windows application developers to write file output routines that are guaranteed either to succeed completely or to fail completely.