Free Newsletters

   All InfoWorld Newsletters
Enterprise Desktop | Randall C. Kennedy » Vista's Broken "Time Machine"

October 28, 2007 | Comments: (0) | TrackBacks: (145)

Vista's Broken "Time Machine"

With all of the recent OS X 10.5 coverage I was curious to see how many of the supposedly "new" features I could reproduce under Windows Vista (i.e. how many ideas they stole from the competition).

Take the much ballyhooed "Time Machine" feature. Vista users have had access to real-time backups for nearly a year now. It's called the Volume Shadow Copy Service (VSS), a kind of limited journaling capability that's integrated seamlessly with the Windows shell. Right click on any file, select "Restore previous versions" from the context menu, and…Voila! You're presented with a selection of archived versions that you can restore with a simple mouse click.

VSS is a great feature. However, unlike "Time Machine" - which copies files to an external disk that can be unplugged and taken with you - VSS is restricted to making archival copies within the local file system. To reproduce all of "Time Machine's" functionality you need to involve another Windows Vista component: Backup.

Vista's file and image backup utilities are marvels of simplicity, especially if you use an external hard disk as your backup target. Just select which file categories you want backed-up (e.g. Documents, Music, Videos), set the frequency and time-slot (e.g. Daily at 3AM), and forget it. Vista dutifully backs-up your data as scheduled. No muss. No Fuss.

Best of all, the file backup utility in Vista is fully integrated with the aforementioned VSS. Now, when you open a file's properties and select the Previous Version tab, you're presented with a list that includes both Shadow Copies from the local file system and the copy that was backed-up to the external disk during the scheduled file backup session. Restoring the backup copy is as simple as restoring a Shadow Copy: Point. Click. Done!

When I tried this scenario on my own system I was amazed at how easy it was to implement. One minute I was staring at a newly modified document. Then a few clicks later I was looking at the version from the day before. I could even keep both copies - the utility simply renamed the older version and placed it alongside the newer one. More importantly, it did so without involving any clunky Backup/Restore interface. Everything took place within Explorer - just like a normal VSS operation.

Needless to say, I was impressed. Not by the technical feat itself - after all, it's just file backup with a bit of journaling thrown in - but rather by the seamlessness of the integration. You didn't need to think about the "what" or "where." It just works…period. For the first time in years I was actually tempted to drop my tried-and-true manual approach (basically, the equivalent of xcopy with some additional steps) and trust my precious data to Microsoft.

Of course, the story doesn't end there. In fact, my odyssey into Vista's backup purgatory was just beginning. You see, shortly after my brush with apparent backup ecstasy, I made a disturbing discovery: Not all of my data files were being backed-up.

I realized this while I was browsing through the source code to one of my ASP.NET web development projects. Some files, most notably the ones with a .vb extension, were being picked-up by the utility. Others, like those with an .aspx extension, were not. I could tell because the excluded files didn't have the tell-tale "Backup" entry in the Location field of the Previous Versions list. In fact, there were no Previous Versions at all. Backup had completely ignored these files, as it had many others in my "dev" folder - this despite the fact that the folder itself was nested within the user Documents folder.

A quick search of the utility's "Restore" catalog confirmed my suspicions: Vista Backup had excluded large swaths of my critical data files (again, all located within the user Documents folder - a major oversight) while picking up all sorts of unrelated junk from Program Files and other, non-user specific folders. In fact, the selection criteria appeared to be almost entirely random, so much so that I concluded the utility itself must be broken. But when a quick search of the web turned-up other users experiencing similar "gaps" in their backup coverage I knew it was over.

My Vista backup dream was smashed. I now realized I could never rely on a mechanism that a) doesn't allow me to directly specify the file set and b) makes seemingly arbitrary decisions on what to keep and what to discard based solely on the whim of some mid-level Microsoft program manager and his/her focus group of "typical Windows users."

Undaunted, I decided to take a different route. This time I downloaded the Windows Live Onecare 2.0 Beta and proceeded to test-drive the suite's backup utility. With Onecare, I finally got what I wanted - full control over the source file set - however, in doing so I lost the very functionality that spurred me to begin this quest in the first place: Seamless integration with VSS.

It seems that the Windows Live Onecare folks didn't do their homework when they were cooking-up their replacement for the less flexible - yet technically more sophisticated - Windows Vista Backup utility. Instead of leveraging this powerful, well-integrated UI feature (VSS), they ignored it entirely. So now I'm left with two choices: Accept the Oncecare solution and forego all of that integrated VSS goodness; or seek out a 3rd party utility that properly leverages VSS while providing the level of control I need.

Or I could just go back to my manual technique, perhaps augmented with something like SyncToy to minimize the transfer size. But what I'd really like to do right now is borrow one of those Apple "Time Machines" and roll my life back to the point right before this past weekend when I was pondering how to reproduce this same functionality under…hey, wait a minute! Who took my hard disk?!

Posted by Randall Kennedy on October 28, 2007 12:10 PM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




Are you sure? I have tested quickly with an aspx file and it seems works.... I mean the Restore Point part. I am not sure about the backup utility, and I agree with you- I wont trust a backup utility without options on choosing which folder/files to backup, thats just too stupid.

Posted by: goodwill at November 12, 2007 09:23 AM

goodwill,

Yes, the Restore Point/VSS functionality works just fine. It's the Backup utility that's the problem. It skips .aspx files since it considers them to be "system" files. And as you're obviously aware, this could be a huge oversight on a developer workstation. As I mention in my follow-up post, the solution is to ZIP-up all your important code files/folders and then enable the "Compressed files" option in Backup.

RCK

Posted by: Randall C. Kennedy at November 12, 2007 09:31 AM

Zip them all is stupid- I rather buy something if I really have to backup properly. I guess thats how MS make Veritas/Symantec get their food :)
So at least the restore point works...
I will do some test on the backup ASAP to find out what happen, keep you updated if I saw anything interesting.

Posted by: goodwill at November 12, 2007 05:11 PM

I have just been severely burned by this having put my faith into Vista's backup utility. Did Microsoft not think that some of the people "upgrading" to Vista may be developers.

I have just lost a year's worth of work because the vista backup utility did not include my .aspx pages.

I could not see anywhere in the help section for the utility that lists the types of files not included.

This is just completely unacceptable and Microsoft need to start taking some responsibility rather than just presuming their products cover everyone's needs.

Posted by: Ben Foster at December 24, 2007 02:16 AM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links