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.
These instructions assume you're using a sparsebundle file in 10.9 because you use an encrypted drive. If not, modify accordingly.
First, follow the instructions in the link below to figure out how to use security find-generic-password
to grab the password to your encrypted drive out of your Keychain programmatically.
http://blog.joshdick.net/2012/10/14/programmatically_mounting_encrypted_disk_images_in_os_x.html
Then create a file called mounter
in your local bin directory ~/bin
that contains the following code (replace all paths with your paths, and in the security find-generic-password
, use the name of the key in Keychain):
#!/usr/bin/env bash -e
PHYSICAL_DRIVE_PATH="/Volumes/Backup/"
SPARSEBUNDLE_PATH="/Volumes/Backup/TimeMachine.sparsebundle"
SPARSEBUNDLE_MOUNT_PATH="/Volumes/Time Machine/"
# Check existing states
if [ -e "$SPARSEBUNDLE_MOUNT_PATH" ]; then
echo "Already mounted."
exit 0
fi
if [ ! -e "$PHYSICAL_DRIVE_PATH" ]; then
echo "Physical drive not attached"
exit 0
fi
if [ ! -e "$SPARSEBUNDLE_PATH" ]; then
echo "Virtual drive not found on physical drive"
exit 1
fi
# The mount command uses security find-generic-password
# to get the password from the keychain store
MOUNT_PASSWORD=$(security find-generic-password -w -D "disk image password" -l TimeMachine.sparsebundle)
printf $MOUNT_PASSWORD | hdiutil attach -stdinpass -mountpoint "$SPARSEBUNDLE_MOUNT_PATH" "$SPARSEBUNDLE_PATH"
This is a bit verbose, but means no storing passwords anywhere but keychain. In any case, now we have to get it to run. Create a file in ~/Library/LaunchAgents/
like ~/Library/LaunchAgents/com.martorana.dave.mounter.plist
and put the following code in it, replacing, of course, the paths with your own paths:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.martoranas.dave.mounter</string>
<key>Program</key>
<string>/Users/dave/bin/mounter</string>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>60</integer>
<key>StandardOutPath</key>
<string>/Users/dave/bin/ldout.log</string>
<key>StandardErrorPath</key>
<string>/Users/dave/bin/lderr.log</string>
</dict>
</plist>
We're using launchd
instead of cron
for a host of reasons, the most important being access to your keychain.
Now load your launch daemon:
launchctl load -w ~/Library/LaunchAgents/com.martoranas.dave.mounter.plist
And that should do it. Now launchd
will run your shell script every 60 seconds, and if not mounted and available, will mount your sparsebundle
disk image.
Cheers,
Dave
Best Answer
As it turns out, I needed to make the user whose account is being used to authenticate to the Time Machine mount point from the remote laptop the owner of the
MightyMac.sparsebundle
file. I discovered this by comparing the permissions on the new sparsebundle it created with the old one I wanted to backup to and found the new one was owned by the remote user and the old one was not.After I made the remote user owner of the old sparsebundle Time Machine backed-up to the old sparsebundle file.