View Full Version : How can I recover sparsebundle space?

06-08-2016, 08:58 AM
I run a weekly copy that uses a script to restrict the copy to a single folder on the source disk, updating a sparsebundle file. The source folder is now significantly smaller, having had many of its files removed. (It used to be over 300gb. The source folder is now just over 18gb.)

The sparsebundle file, however, is taking over 500gb on the backup drive.

The copy seems to think it is only copying the 18gb folder -- here are 2 lines from today's log:
Copied 192 items totaling 18.32 GB (33 directories, 159 files, 0 symlinks)
Cloned 18.96 GB of data in 1150 seconds at an effective transfer rate of 16.49 MB/s

When I mount the sparsebundle I see that it only contains the one folder, with the expected contents.

How can I reclaim the space so that the sparsebundle is taking closer to the size of the folder of the source? Yes, I suppose I could delete the bundle file and recreate the scheduled copy, but I'd like to know, in general, if there is a proper way to reclaim space.

06-08-2016, 11:10 AM
You can use a command line tool, hdiutil, to recover some of the space:

hdiutil compact /path/to/bundle/file

Hope that helps!

06-09-2016, 12:10 PM
Thanks! I ran the utility and I got this message at its completion:

Finishing compactionů
Reclaimed 466.1 GB out of 470.3 GB possible.

The finder view still shows the 519.33gb file size. Will that be corrected the new time I run the backup?

06-09-2016, 12:58 PM
No - if it didn't actually shrink the bundle, it sounds like the system determined it couldn't really shrink it. Note, too, that it's generally a mistake not to have the space for the bundle - perhaps you should resize the bundle (using the resize verb) to something smaller, if it's always going to be small?

06-09-2016, 01:33 PM
I was about to try the resize (after some research on it) and found that after dismounting the external HD and remounting it, the size now does appear at the smaller size. So it did apparently work with the compact -- it just wasn't reflecting that without some form of refresh to the volume info.

Yes, at this time it's going to be smaller -- but, of course, grow by smallish amounts as files are added (and removed). But not by the order of magnitude that was its former, original size.