I use a large (presently 16GB) sparsebundle as a container for all of my professional work. This is convenient for me because it is an isolated, secure, "portable" entity where all of my work can be stored in one place. It has persisted over three laptops and several hard drive changes (basically copy it from one to another as needed). It has worked great. In the past, I've used ChronoSync as my backup utility of choice: separate documents to backup drive excluding sparsebundle, then a second document to backup the mounted bundle as a filesystem -- thus, entire bundle is not copied every time, just changed files. But, I have recently started using Time Machine given the wonderful integration it provides. However, I'm not convinced it is handling this large sparsebundle properly:

  1. I can't seem to access it via the Time Machine itself. The only option presented is "restore". I don't want to "try" that out. I created a test bundled (100MB) with the same security. I put a few files in... manual backup via TM... added a few more... manual backup... deleted a few... manual backup. However, when I restore those via the TM interface, the changes don't seem to track. There is indeed a backup instance for each manual backup, but the instances don't correspond to the changes made. Perhaps I am going faster than the system is actually writing to disk? (probably 1 minute between changes).

  2. Directly accessing the filesystem (Backups.backupdb) shows the large 16GB sparse bundle present in most (all?... haven't checked) backup instances (e.g., 2013-02-28-042451). The filesystem reports it as 16GB, prompts for the password if I attempt to mount it, but then fails with "no mountable file system". I guess this is to be expected as I don't think Time Machine backups up the ENTIRE bundle each time... but I can't even mount the ORIGINAL bundle from the first backup, which I would presume is a true copy.

The questions are: does Time Machine definitely handle large sparsebundles properly? Should I be concerned about my testing with the small bundle? Is there any way to access individual files within a Time Machine backup of a large sparsebundle, or does the whole bundle need to be restored?

  • How do you mean access it via Time Machine?
    – mmmmmm
    Commented Feb 28, 2013 at 14:26
  • @Mark "Enter Time Machine"... browse history. I can "QuickView" the sparsebundle instances, which basically shows the size and date. The only other option is "restore". With other individual files in the backed up filesystem, you can see if they are present, names, etc.
    – jjwebster
    Commented Feb 28, 2013 at 15:31

2 Answers 2


Time Machine works at a file level, with no facility to perform incremental changes within files. As such, your Sparsebundle may be backed up in it's entirety every time it changes in the slightest, depending on how large it is. Of course, you have to wait up to 1 hour (+the time it take to make the backup, depending on how large the queue is and where your file sits in it) to ensure those changes are included in the backup. Also if your Sparsebundle is in use (mounted...) then it may well skip it until the file lock is freed

This is a terrible system, and one that we might not see change until the underlying filesystem is suitable upgraded (or replaced) to include such useful facilities as incremental block level changes rather than simple file level ones, and/or deduplication etc. One early victim of this scenario were users who used the original Filevault system for encrypting their home folders. Time Machine would not backup their home folders until such time as they logged out because the Sparseimage file was constantly locked by the fact the user had it mounted. And even when the user did log out, it would proceed to make a hugely inefficient backup of the whole thing again and again - on the assumption that they simply logged out and didn't just turn off etc... Not very clever. To try to ameliorate this the Sparseimage spec was ammended to allow for Sparsebundles. Instead of a single big file, a sparse bundle is a bundle (directory) containing a number of files called bands, each in the order of 8 MB in size. This means even though to the end user the sparse bundle appears as a single file, it is composed of smaller files. As of Mac OS X 10.8, the bands are 8.4 MB each. When the content of the image changes, one or more band files is changed, created, or deleted. This allows backup software (such as Time Machine) to operate more efficiently, but it's just a bodge to attempt to mimic block level changes in individual files, which is limited to 8Mb "blocks"...

So to answer your questions directly, 1) it handles them properly, where properly means the same as any other file, it's just that your particular use (leaving it open and mounted) may not result in efficient backups that are taken regularly, especially if you rarely unmount the file, and 2) yes, you will need to pull back the whole file to view it's contents. The TM restore interface is also file specific. It may have quick-look plugins to allow you to view simple files inline like JPGs etc, but not for a complex file like a sparsebundle.

On the bright side, you already have a licensed copy of ChronoSync, which is super useful, and I would continue to use this to perform incremental backups of your sparsebundle whilst it is mounted, you can use the same drive as your TM images too.

  • Thanks for the answer. However, I'm not sure that is the case: If I use DaisyDisk (for example), I can see instances of the sparsebundle in each backup -- the first backup is a bundle that is 16GB (as expected). Each additional bundle is much smaller -- MB, only... presumably tracking individual changes to the bundle?
    – jjwebster
    Commented Feb 28, 2013 at 15:33
  • We are both right, I'm about to amend my answer :)
    – stuffe
    Commented Feb 28, 2013 at 15:38
  • This answers my question. So: 1. TM does handle sparsebundles properly, but only when they are unmounted. 2. there is no way to view individual files in a TM-backup of a sparsebundle; the whole bundle needs to be restored 3. TM is efficient in backing up sparsebundles, albeit with 8.4MB granularity (which, in my mind, is a fair compromise until block level changes are supported in TM). Thanks!
    – jjwebster
    Commented Feb 28, 2013 at 16:53
  • I presume the reason that the sparsebundle needs to be unmounted for it to backup with TM is to avoid data changing while it is being archived? Why is it, then, that neither ChronoSync or SuperDuper (when dealing with an entire drive) have this issue? Can TM be made to work on a mounted volume?
    – jjwebster
    Commented Feb 28, 2013 at 17:10
  • TM is backing up the Bundle file (or, rather, the hidden band files). Merely having the bundle open should lock these files as being used. However, Chronosync is not looking at the Sparsebundle, and doesn't even know the files inside are even inside one. It is just looking at the individual files within it, as they are made available through mounting it. To use a poor analogy, the OS (TM) is looking at the packaging, CS is looking at the contents.
    – stuffe
    Commented Feb 28, 2013 at 17:55

The only time I've seen the error you report was when I stored a sparse disk bunds inside another sparse disk bundle and both were remotely mounted on a fairly slow network storage device such as a Time Capsule.

In those cases, I've often excluded the original image directory from the Time Machine backups, since it works in theory (and most of the time in practice), you can't get any benefits of browsing those files on a Time Machine backup.

I usually set up rsync or another incremental backup tool to copy those files on a schedule I like (perhaps automating it all with Lingon 3).

By restoring the file to a local drive, you'll know if the failure to mount is due to an actual corruption or just network indirection and time out.

Once it's copied to an attached or internal disk, you might also be able to use Disk Utility to patch up filesystem errors although with encrypted sparse disk bundles, that is often not successful.

  • I've seen reports of those errors in the Google search I performed before posting. I should be careful to note here that I don't think anything is actually corrupted. I'm just erring on the side of caution before I totally trust my backups to Time Machine. I could certainly use rsync (did that often back in my days of being an exclusive Linux user)... and could use ChronoSync... but I really would like to know if Time Machine and its wonderful integration can do it all for me.
    – jjwebster
    Commented Feb 28, 2013 at 15:36
  • The no mountable file system is basically a corruption. The helper that decrypts the bands into a filesystem has found an error and bails. Again, it is supposed to work - and when you use finder or other tools that don't realize a hard link is used by Time Machine to show each band file in every backup interval, yet only store one copy of the band means that calculating a directory size over estimates how much space on disk is actually used.
    – bmike
    Commented Feb 28, 2013 at 15:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .