I keep different types of data in different encrypted sparsebundle images (say, one for each client) which automatically mount upon login but can't be opened by anybody other than myself. So, after login I have a number of virtual volumes in /Volumes/ which keeps my client data both secure and organized.

How do I include data inside these virtual Volumes in TimeMachine's backups, or data residing in any path on any partition/volume?

I found a promising solution description (blog post no longer available online) involving editing the com.apple.TimeMachine.plist but all I can get TimeMachine to do is backing up the sparsebundle files themselves. I want it to back up the files inside the mounted image, though - something like adding /Volumes/Client_abc/ to TimeMachine's search path.

Please do not redirect my to this previous question as it doesn't solve the problem at all. Please also refrain from telling me why you think I should not want this answer as that will not solve anything either. Please lastly don't say "it can't be done" unless you can technically prove that claim.

  • The problem with backing up an encrypted sparsebundle in Time Machine is that it'll save the whole encrypted container and any change inside of the sparesebundle will cause the whole image to be saved again. Unfortunately, there are not very many alternatives because backing up the files inside of the mounted volumes (if possible) would cause the encrypted files to be stored in plain text on your backup drive. I believe OS X Lion will support more encryption features. – Bandit May 23 '11 at 12:29
  • @bandit are you confusing sparseimages with sparsebundles? Even if the sparse bundle is encrypted any changes to the mounted disk doesn't cause every band in the underlying bundle to be modified (I just tested it to be sure) and so TM will only back up the changed bands, not the entire sparse bundle. Also, why not just make TM back up to an encrypted image to keep things encrypted after backup? – Buxtor May 29 '11 at 0:00
  • The notebook can be stolen so it's vital to have the data inside an encrypted image while on the go. The backup storage is in a data center behind thick doors and armed guards - the data can very well be stored unencrypted there because the risk of loss is very close to zero there. – Olfan Jun 1 '11 at 12:56

I've found the solution by reading the Time Machine manual and tons of blog posts, Q&A site answers etc. Everywhere it says "Time Machine will not back up data on removable media, just live with it or use strange hacks.".

But that's exactly it, and it's so obvious! A mounted .sparsebundle image is seen as removable media.

So all you need to do is mount your .sparsebundle (encrypted or not doesn't matter), or a USB stick or whatever should appear backed up in Time Machine, as non-removable media.

This little piece of AppleScript will do the trick:

do shell script "hdiutil attach /path/to/your.sparsebundle -notremovable" with administrator privileges

The "-notremovable" switch will take care that the image is mounted as not removable, and the "with administrator privileges" phrase will pop up a password requester to mount the image as root and not as your logged in user account. Now to Time Machine your mounted volume is just a hard disk which it will no longer ignore. Funnily enough, thus mounted media can still be unmounted at any time so while they technically stay removable, logically they aren't anymore.

You can save that AppleScript as an Automator application and include it in your startup items so you can always have your current work environment be ready for you at login time.

There is a caveat, though: Do make sure your image is mounted whenever Time Machine starts a backup run. If it is missing just once, Time Machine will believe that all the data in it is now gone. If it is present the next time, Time Machine will regard all that data as new and make a full backup of the whole image's contents — this can rapidly fill up your backup drive and thus lead to a severe loss in backup history as Time Machine will start to delete old backups without asking when space becomes scarce.

Edit: Since OS X Lion FileVault 2 can encrypt the external backup drive so nobody can just steal your backup and restore the unencrypted data from there anymore.

  • This has been tested and is in use on a Lion (10.7.1) installation. I'm eager to receive feedback regarding Snow Leopard or older OS X versions. – Olfan Sep 27 '11 at 8:11
  • This has been tested and is in use on a Mountain Lion (10.8.1) installation now as well. Yes, there's FileVault 2 now and I'm using that, too. I do like to have my different client's data in separate volumes, though. – Olfan Sep 10 '12 at 8:23

I think the article you found is for an older version of Time Machine because I followed a more recent guide and I can confirm it definitely worked using Mac OS 10.6.7. The main difference in the articles is that Time Machine appears to have moved away from using UUIDs to Alias records in its plist file.

This is what I did:

  1. Stop Time Machine in System Preferences and then quit System Preferences (otherwise your manual edits can/will be overwritten when System Preferences eventually quits)

  2. Using your favourite plist editor open the time machine settings file, found here: /Library/Preferences/com.apple.TimeMachine.plist

    I recommend using the shareware editor Plistedit Pro rather than, say, Xcode because it will allow you to save the original file as root, requesting an admin password, rather than Xcode needing you to save the file into user space and then you needing to overwrite the original file using root privileges from the command line.

  3. in TimeMachine.plist look for the node IncludedVolumes. Add it as a child of the root node if it's not there, it should be an Array of Data items.

  4. Add a new item to the IncludedVolumes array of type Data with a value that is an alias record of the path to the mounted encrypted volume.

    If you use Plistedit Pro then generating the alias record is easy. Once the new item is set to be type Data you can right-click the value field and change the View As property to be Alias Record. Then you right-click the value field again and choose 'Edit Value...' then type in the path to the mounted volume, e.g. /Volumes/MyEncryptedVolume. If you change the view type back to just Data then you can see the alias record is now converted to a binary string. Ensure the encrypted volume is mounted beforehand as Plistedit will attempt to validate the alias and will complain if the path does not exist.

    Xcode doesn't appear to have this ability to generate alias records on the fly. The source article suggests mounting and opening the sparse image in Finder so that it appears in Finder's Recent Folders list, then opening the ~/Library/Preferences/com.apple.finder.plist file and copying the value from the FXRecentFolders/file-data key where the sibling name item matches the name of the encrypted volume.

  5. Ensure the path to the encrypted volume isn't also mentioned in any of the values in the ExcludeByPath, ExcludedVolumes, SkipPaths arrays.

  6. Exclude the sparse bundle from Time Machine so that you don't back up the volume twice. Add the path to either the ExcludeByPath array or the SkipPaths array. The only difference I can tell is that the items in SkipPaths is shown & also editable in the Time Machine control panel, while the paths in ExcludeByPath are completely hidden in the control panel. Either way, TM will ignore the directory.

  7. Save the TimeMachine.plist file ensuring that the owner:group is still root:admin

That's it. Switch Time Machine back on in System Preferences and you should now see the contents of your mounted sparse bundle in its own backup directory as a sibling to the Macintosh HD directory, e.g. /Volumes/Backup of ComputerName/Backups.backupdb/ComputerName/Latest/MyEncryptedVolume

But in fact, while I trialled this for around 3 months and it worked for me I don't configure Time Machine like this anymore because:

  1. If a sparse bundle is unmounted when Time Machine runs then the volume is understandably skipped during that backup. However when the sparse bundle is subsequently mounted Time Machine will back up the entire volume again, copying all files as new files into the back-up, it doesn't just create a hard link to any files already existing from earlier backup folders. This was the show-stopping issue for me since I don't have every image mounted 100% of the time.

  2. Obviously this an unsupported custom configuration of Time Machine and so may change without warning at the next software patch from Apple. So it's hard to see how this approach could be described as a reliable long-term back-up solution.

  3. Time Machine reports the wrong file counts and file sizes in the console log during back up, which doesn't fill me with confidence that TM is cut out to be configured this way, even though the files do appear backed up correctly on the Time Machine Volume (just a paranoia?)

  • As of Lion, this doesn't work anymore. Any removable media mounted under /Volumes/ will be completely ignored, no matter how hard you try to include it. The new tmutil command line tool even sets both an Alias and a Volume UUID and still Time Machine will refuse to back up the files. See my own answer for a safe and easy way. – Olfan Sep 27 '11 at 8:15

Time Machine has poor support for encrypted containers and can only back up the whole container.

This means you'll either have to buy a large backup hard drive (a terabyte disk is < $100 nowadays)

...or wait until OS X Lion comes out and hope they improve the encrypted volume support.

I'm assuming, of course, that storing client data in plaintext on the backup drive is not an option.

  • It is an option. The backup storage is well enough protected to not need encryption. You'd have to haul a 19" rack out of a data center to steal it. ;) – Olfan Jun 1 '11 at 12:59

Olfan: Thats really great; thank you very much.

I've written a little AppleScript to mount the volume image including the passphrase:

property imagePath : "" -- preset path to image file
set path_to_resource to POSIX path of (path to resource "checkModifierKeys") -- this is the path to the command line utility to detect the modifier keys pressed
if (do shell script quoted form of path_to_resource & " option") = "1" then -- Option key is pressed
    set imagePath to ""
end if
if imagePath = "" then -- first run or Option key is pressed
    set imagePath to choose file with prompt "Image File:" -- let the user select the image file
end if
set thePass to text returned of (display dialog "Password for " & imagePath default answer "" with hidden answer) -- ask for the password
set cmd to "printf " & quoted form of thePass & " | hdiutil attach -notremovable -stdinpass " & quoted form of POSIX path of imagePath -- and set the command incliuding password
do shell script cmd with administrator privileges -- finally submit the command in supervisor mode

You have to save the script as an application and include the "checkModifierKeys" command line utility in the application bundle. You can get it from http://www.klieme.ch/pub/checkModifierKeys.zip

Here is my description of the script:

This little script mounts a volume image as a non-removable disk in supervisor mode. This makes Time Machine backup the contents of this volume as well. You should exclude the image file from the backup to avoid cluttering of your backup volume.

The first time you run this script asks for the image file and remembers that location on subsequent calls. To select a different image file run the script with "Option" key pressed.

checkModifierKeys: Stefan Klieme http://www.klieme.ch/pub/checkModifierKeys.zip

  • 1
    It's not necessary to claim copyright in your posts, they are covered under CC-by-SA already. – jonsca Oct 11 '12 at 10:21
  • On your own Mac(s) you can/should store the pass phrases for your disk images in your keychain, the OS will offer to do that when you first mount it, and hdiutil will check the keychain and use a stored pass phrase if found. On other people's Macs you certainly don't want to circumvent the need for a passphrase. I really can't see what this solution would do for me except creating a security hole in place of an existing and secure OS functionality. – Olfan Nov 4 '12 at 14:27

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