First, here’s a recap of the problem. It’s written in terms of VMware Fusion but should be equally valid for other VM engines such as Parallels Desktop. If you’ve already read the previous article then you might want to skip to the meat of this article.

Large backups

When you’ve been using Fusion’s virtual machine (in my case, to run Windows), you will find that Time Machine’s backup takes longer than expected — sometimes much longer.

This is because Fusion stores its virtual machines’ disks as a bunch of large files. When you run your virtual machine using Fusion (or Parallels Desktop), the contents of the VM’s virtual disk changes, and even if you haven’t made many explicit changes to files, all sorts of small changes happen to the virtual disk’s contents.

Incremental can still be too much

Time Machine performs incremental backups. That is, it copies only files that have changed since the last backup. Unfortunately those large files that Fusion uses to store the virtual disk’s contents? They’ve probably all changed, at least a little.

So, instead of your incremental being a few megabytes and taking a few tens of seconds, it’s ten gigabytes, takes ages, and rapidly fills your backup disk. (Which causes its own problems: described here.)

One solution: back up the VM in another way

One solution is to keep all your precious files in the Mac file-store, tell Time Machine to avoid backing up your virtual machine(s), and then back them up some other way. This results in the smallest backups and is useful if you don’t need sophisticated incremental backups of your virtual machines.

If this sounds like you, then I’ve shown how this can be achieved in an earlier article.

An alternative solution: use a sparse bundle

If you need proper incremental backups of your VMs, then one approach is to use a sparse bundle. This is a disk image which is stored  as a collection of small files (typically 8MB), so when Time Machine backs up the disk image, it only needs to copy the files that have changed.

This approach still isn’t perfect — when (for example) Windows does anything, it tends to scatter its writes over the disk, so incremental backups are still large, but they’re not as large as when Time Machine backs up the VM directly. Typically, your incrementals may be a few hundred megabytes with no VMs, a few gigabytes with a VM stored on a sparse bundle (for Windows. Linux may be better behaved), and a few tens of gigabytes with the same VM stored in the standard way.

Here’s how

First lets create a new disk image based on a sparse bundle and move our VM onto it. We’ll need to know how large to make the VM, so go to Documents and look in Virtual Machines. In there is one folder per virtual machine and you can find the VM’s size by clicking on the corresponding folder and hitting cmd+I:

Create the disk image

Now create the sparse bundle. The point-and-click way of doing this is to use Disk Utility, so start that up (I use spotlight to do so):

and click on New Image:

Then fill in the details. I made my sparse bundle file-system for the Windows XP VM twice as large as the space it currently occupies, to allow for future expansion — so 50GB in my case (don’t worry: it only uses as much real disk as is needed to store the actual content). Here’s all the fields you need to change:

• The Save As is the filename for the sparse bundle whereas the Volume Name is the name the disk will have when mounted — I made them the same;
• I saved my sparse bundle in Documents->Virtual Machines;
• Image Format needs to be sparse bundle disk image, as that’s the whole point of the exercise.

Now click on Create, and

a few seconds later you have a sparse bundle file-system image.

Now double-click that file (mine’s called VM disk.sparsebundle).

Mac OS will mount it…

and the new file system will appear on the desktop.

Move the VM into the new disk image

Next, drag the folder(s) corresponding to the VM(s) you’d like backed up by Time Machine onto the new disk. Hold down cmd as you drag and drop, so that you move the folders (rather than copying them):

Ensure the new disk image is mounted at login

The .sparsebundle file needs to be mounted every time you log in, so that the file-store is available. To do that, go into System Preferences->Accounts, click on your username and then on Login items. Now drag your sparsebundle file into the list of login items:

and that’s it.

Using your newly-homed VM(s)

To use your new VM(s), just double-click on the corresponding folder — perhaps put an alias to it on your desktop or in the dock. When you next use it you’ll get a message:

Just click on I moved it and you’re sorted.

Warning

As with any method of backup which relies on backing up the virtual machine’s disk image using the host operating system, your backup may not be of any use if it’s made whilst the VM is running, so I suggest you make sure that Fusion/Parallels is not running when Time Machine is backing up your data. If you don’t always manage to do so then some of your backups may not be valid.

Why?

Because if you backup the files that Fusion (or Parallels) is using for a disk image, then you’re backing up what’s on disk, but not what’s in memory, in disk buffers, etc. So when you come to restore from backup, you may find that the disk image is corrupted. In the worst case scenario you won’t be able to start up the VM’s operating system successfully at all, or restore any files contained within the VM’s file-store.

By backing up when the VM isn’t running, you ensure that all data is on disk in a safe, consistent state.

No related posts.

Coming to Mac OS X from Windows (XP and Vista), I missed being able to lock my session using a simple key-chord. I work in a shared office so it’s sensible to lock the session every time I walk away — something I do regularly.

In Windows, you simply press Windows-L and that’s it — time to go. Mac OS X Leopard doesn’t provide anything as succinct as standard, but there are ways.

Firstly, there are a couple of solutions that are accepted as standard ways of doing this — but unfortunately both have problems. I’ll cover these methods first in case they work for you, and then I’ll cover a solution that really is as quick and easy to use as the Windows’ lock screen key chord.

Partial solution number one: use a hot corner

A hot corner allows you to drop into the screen saver by moving the cursor to a chosen corner of the screen. To do this, first go to System Preferences->Desktop & Screen Saver and click on Hot Corners… Then select Start Screen Saver for one of the corners:

Now, when you place the cursor in that corner (I chose the bottom-left), the screen saver will start.

Of course, this doesn’t help unless your system is configured to require a password when woken from the screen saver. You can set that in System Preferences->Security:

And that’s it. Now, before you walk away from your Mac, just drop the cursor into the bottom-left corner of the screen.

However, there is a problem with this method — at least for me — as I don’t want the system to prompt for a password on wakeup. I end up typing my password far too often — every time I’ve left the machine alone long enough for the screen saver to start.

What I want is the Mac to remain unlocked until I explicitly lock it. So, on to solution two…

Partial solution number two: select a pull-down from the menu bar

Here’s another way of locking the machine, and this one doesn’t require that you tick Require password to wake up this computer from sleep or screen saver.

The trick is to enable fast user switching in System Preferences->Accounts->Login Options:

which will then place your user name in the menu bar at the top of the screen.

When you want to lock the session, just click on your user name:and select Login Window… and you’re done. (You can also achieve a similar result by ticking Show Status in Menu Bar in Keychain’s preferences if you prefer.)

What’s my beef with this solution? The problem is that it’s still rather slow and fiddly — and it’s something I do regularly, so I want to just press and go, just as I did with Windows.

A full solution

To implement a full Windows-L style solution we need Dockables to provide us with an application that locks the Mac OS session, and Quicksilver to launch that application.

First, download and install Dockables from cocoaapp.com. This gives you a bunch of useful applications in a sub-folder of your Applications folder:

and the one we’re interested in is Lock Screen.

Next, download and install Blacktree’s Quicksilver and run it to configure a new Lock Screen key-chord. Quicksilver will present you with its main window — just quit that and instead move to Quicksilver’s menu bar at the top of the screen and select Triggers… from the drop-down menu.

In the Triggers window that appears, click on the + at the bottom and select HotKey.

A new window will appear. Click on the first field and start to type lock screen. Quicksilver will rapidly find the Lock Screen dockable you installed earlier. Click Save.

Nearly there

You now have a new command, but with no trigger. So click on the None in your new command,

click in the input field labelled Hot Key: and press the key combination you wish to use to lock your session from now on. (I chose alt+cmd+L because the obvious choice – cmd+L — is already used by Thunderbird — my email client.)

I suggest you don’t use the ctrl key as part of your hot key-chord. If you do then quicksilver presents this dialog every time you type the chord:

Now, having typed a key-chord (which doesn’t include ctrl), exit the Triggers window and you have yourself a new Lock Screen hot key-chord: alt+cmd+L in the example above.

And finally, tweak some settings

You need quicksilver to run at all times, so bring up Quicksilver’s preferences (available from the Quicksilver menu in the menu bar at the top of the screen):

and tick Start at login. You may also want to tidy up the dock a little — as quicksilver is running all the time I’d rather it didn’t appear in the dock and instead appeared in the menu bar:

so I untick Show icon in dock (and I also tick the option check for updates):

And that’s everything sorted. Any time you need your display locked, just type alt+cmd+L…

and walk away…

No related posts.

A source of frustration

Not dangerous, but irritating until you figure it out: when an application is not the foreground app (i.e. mouse and keyboard input isn’t going there at the moment and the application’s menu bar is not at the top of the screen), then clicking on the application’s window will make it the foreground app, but the mouse click is not forwarded to the application.

So for example: with Windows, clicking on a link in web browser will follow that link, regardless of whether the application is the foreground app. With Mac OS X, if some other application is currently the foreground app then your first click will just select the web browser as the new foreground app — it will take a further mouse click to actually follow the link. So with Mac OS X you often have to click twice.

More dangerous

Dragging a folder to somewhere that already contains a folder of the same name results in very different behaviour. If you’re used to Windows then you may lose data.

Say I have a new Franz Ferdinand CD ripped and ready for my music collection. The music is in a folder named after the album, which is itself in a folder named after the artist.

With Windows, I can drag the new ‘Franz Ferdinand” folder from my ripping area to my music area and it will say

I say yes and it’s job done. The new Franz Ferdinand folder’s contents will be merged with the existing Franz Ferdinand folder’s contents in my music collection.

With Mac OS X, the OS says

Note the difference: ”Franz Ferdinand” is being replaced. So if I click on replace then all my previous albums by that artist are gone — not at all what I intended!

Another subtlety

There are others, I’m sure, but another dangerous difference in file manipulation when you’re used to the way Windows does it is this:

Drag a folder from one file-store window to another and then change your mind and hit delete (cmd+backspace in Mac OS X).

Under Windows, the destination window is now in the foreground, so you end up deleting the destination copy.

Under Mac OS X, the destination folder is highlighted (hint: it’s highlighted in grey not blue — that’s the subliminal cue), but it’s still the source finder window that’s the foreground app, so you end up deleting the source rather than the destination copy.

As with much of the Mac OS X vs Windows behaviour, the Mac OS way is usually better thought out, but that doesn’t stop it from being dangerously different if you’re used to the way Windows does things. Here’s hoping that this article will save some people some grief.

No related posts.