QRecall and VMWare Fusion

I've recently installed VMWare Fusion on our Xserve, which launches Windows XP Pro on bootup, so now our server is simultaneously running Leopard Server and XP Pro, at all times. The Windows virtual machine file, which includes the virtual hard disk as well as snapshots, etc., is stored in my home directory, and is backed up every night.

The virtual machine file is currently about 60 GB in size, and is actually a package. The virtual disk itself is broken up into numerous chunks, each no larger than 2 GB in size. (That's one of the options for how Fusion segments and stores its virtual disk.) There are probably large chunks of the virtual disk that rarely change. But some of the chunks that do change, such as those parts that contain Windows log files, caches, temp files, etc., probably change fairly constantly.

So, I'm wondering how QRecall deals with this. Even though QRecall is backing up only the parts of the virtual disk files that change, it still takes significant time to back them up, and they're continuing to change during the backup. If I ever have to use QRecall to restore the virtual machine file from a backup, is it (the VM file) even likely to work? Or do I end up with a virtual disk inside the VM file in which the various chunks are no longer consistent with each other, because they were backed up at different times during the archive session?

Would I be better off to not back up the VM file until the virtual machine is not running? That would probably be tricky to implement, since the server needs to run unattended, but I might be able to come up with something if necessary.

Bruce Giles wrote:The virtual machine file is currently about 60 GB in size, and is actually a package. The virtual disk itself is broken up into numerous chunks, each no larger than 2 GB in size. (That's one of the options for how Fusion segments and stores its virtual disk.)

This is a popular trend in large disk images, primarily so that file-oriented backup and synchronization applications don't have to copy the entire image every time.

So, I'm wondering how QRecall deals with this.

QRecall deals with this like any other set of files. It recaptures any of segment files that have changed since the last capture, analyzing each one for changed data.

Even though QRecall is backing up only the parts of the virtual disk files that change, it still takes significant time to back them up, and they're continuing to change during the backup. If I ever have to use QRecall to restore the virtual machine file from a backup, is it (the VM file) even likely to work? Or do I end up with a virtual disk inside the VM file in which the various chunks are no longer consistent with each other, because they were backed up at different times during the archive session?

The fundamental problem here is that the files are changing during the capture. The fact that there are multiple files is immaterial; the problem is essentially the same whether there were one file or a hundred.

It doesn't matter what backup/copy/synchronization utility you use, the inescapable problem is that the contents of the file are an incomplete representation of the current state of the application. This is also true for database files, dynamically modified document files, and so on. But it's particularly true for disk images, since the directory structure of the disk will more than likely be inconsistent with what's buffered in memory.

The same problem exists when you capture the OS X operating system. It's possible because most of the files that are constantly being modified aren't that significant. These include log, cache, scratch and temporary files along with memory mapped files. Failing to capture all of the data that should be in those files doesn't prevent your system from restarting.

I suspect that the same would be true for the VMWare disk image. Most of the files (the OS, applications, documents, ...) would be stable and are dependably captured. The one transient data structure that's most likely to give you problems is the directory structure itself. After recalling an older version of the VMWare disk image, I would immediately repair the volume before proceeding. If you have the disk space, I think it would be a good experiment to try this a couple of times using various captured images.

Would I be better off to not back up the VM file until the virtual machine is not running?

That's the only real solution—and that's independent of what backup solution you're using.