I have a Windows SBS 2008 here that I'm trying to restore from backups. It runs as a VMware virtual machine, so I can use snapshots and try out stuff.

What happened

Windows froze and the only option I had was to hit the "reset-button". After that I checked the filesystems and found that the filesystem on the system-partition is broken, everything else is ok. The system is currently working although it has filesystem-errors but I'd rather not leave it this way and wait until it blows up in my face. I created a snapshot and gave chkdsk a shot on repairing NTFS, but as it turns out chkdsk breaks the filesystem completely as the OS won't boot afterwards and also chkdsk cannot be run a second time, because both hang while constantly reading from the disk with 400kb/s. I let chkdsk run for a day at one time just to see if it maybe finishes or at least shows some progress. I also tried every newer version of chkdsk. So my decision was to restore the whole thing from the backups.

The problem

I set up a second VM with identical virtual hardware and installed an SBS 2008 on it. I installed all Windows Updates in the same servicepack level as the current installation and took a snapshot of that state. I'm trying to restore from three separate backups: systemstate, exchange and additional data. Every recovery I did so far failed because something breaks while restoring. The first time exchange was broken after recovering the systemstate, store.exe just kept crashing when trying to start it, so I could not restore the exchange databases. And currently, I got everything restored and even exchange is working but .Net Framework and Windows Installer are broken. Windows Update is broken too but that is probably because Windows Installer is broken. I tried fixing both without success.

My Question is, is there anything I can try/do to save this? At the moment I'm leaning towards migrating to a fresh installation.


The problem is that, as your filesystem got corrupeted, maybe even the backups are inconsistent/corrupted. This is a very bad spot, as data recovered seem consistent (with no error during recovery and no filesystem error) - except they aren't, because data inside the backup was not consistent in the fist place.

Have you any method to check backup data consistency?

| improve this answer | |
  • The problem seems to be restoring the systemstate, which was backed up prior to the freeze. Assuming the filesystem was fine before the freeze, the systemstate backup should be consistent. Filesystems are manually checked in case something happens that could corrupt them. So if the corrupion was there when the backup was created, then it can only have happened during normal operation which I haven't seen happen so far. The backups are always verified after creation. – lsmooth Apr 10 '15 at 9:16
  • "Assuming the filesystem was fine before the freeze" is not a small assumption do make. While journaled filesystem (as NTFS) runs on-demand scan based on dirty-flag state, the problem you are describing let me think that somehow error crept on your filesystem and only after the forced reboot (which sets the filesystem dirty-flag) chkdsk noticed them. In other words, maybe (but hopefully no!) your backup are a consistent view of an inconsistent filesystem More proactive filesystems (as ZFS and BTRFS) have a point here. – shodanshok Apr 10 '15 at 10:09
  • I know but what I meant is: how would I check backup data consistency when I have nothing to verify it against except for the server it was created from which has at least now a broken filesystem? I can only assume it is, if it is not I have no way of restoring from those backups, which is actually why I'm thinking a fresh install and migrating everything would be the best option. – lsmooth Apr 10 '15 at 10:51
  • I ended up reinstalling the server because of this. @shodanshok was correct, the filesystem was broken since quite some time and a restore only restored the already broken filesystem. chkdsk did the rest and corrupted it further each try in a different way. – lsmooth May 4 '17 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.