There is a neat quirk when using the like of the TimeTamer app to create a Sparsebundle to hold Time Machine backups. I’m putting this in a new thread, but it also concerns thread http://www.drobospace.com/forums/showthread.php?tid=1877 where the original question over how to restrict the sparsebundle size with TM was raised.
This seems to be true for Mac OS X 10.6.x, and is a bit of a gotcha.
You create a Sparsebundle as say, 300Gb, when Time Machine runs it will try to re-size this to whatever size your storage reports.
In the console logs, if you look for backupd, you will see it do this…
12/12/2010 21:35:24 com.apple.backupd[368] Resizing backup disk image from 380.4 GB to 16383.6 GB
My DroboPro says it has 16Tb, so it wants to re-size to that. Normally you won’t see it as it would do it on the first run of TimeMachine on a new Sparsebundle and then not report it again.
Naturally, this means your TimeMachine backup can now grow to fill your entire Drobo when using the SparseBundle method.
There is however a neat trick which seems to work to get round this if you are just starting out down this road. Once you create the Sparse file, right click it in Finder and choose “Show Package Contents”, a directory will open and there is an info.plist file there. Get info on that file and Lock it with the ‘Locked’ checkbox.
Now when TimeMachine runs you get this…
12/12/2010 21:35:24 com.apple.backupd[368] Resizing backup disk image from 380.4 GB to 16383.6 GB
12/12/2010 21:36:03 com.apple.backupd[368] Could not resize backup disk image (DIHLResizeImage returned 35)
12/12/2010 21:36:05 com.apple.backupd[368] QUICKCHECK ONLY; FILESYSTEM CLEAN
Everything works as normal, but your storage doesn’t get slowly eaten away.
If you already have Sparsebundles set-up you can re-size them, it just takes a while. Easiest way is to drag the file into DiskUtility and use the Resize Image option - it does take quite a while so be patient. Then again go and lock the info.plist file to prevent the re-size.
I found this when my DroboPro chassis was replaced and I wondered why the TM backups where larger than I had originally set them up to be. I kept them in a folder and didn’t bother to really look at them as everything was working just fine. Some research via Prof. Google discovered this is a “known” issue which has been reported to Apple who believe the re-size is a good thing and so have no plans to fix it. Using the hdiutil command with the shrinkonly flag doesn’t stop it either, seems the only way is to lock the info.plist file.
So, if you don’t follow the Drobo KB article 119 over using partitions, then you too could have ever growing TM Backups.