I've been asking myself this very question, and the answers on here certainly helped. However there's an aspect that's lacking which may be a new implementation "detail" that didn't exist when this question was answered.
tmutil delete
does indeed delete backups, but doesn't actually reclaim the space they took, at least not in any guaranteed way. I spent about 2 whole days deleting backups from >2y ago, which according to final completion message amounted to approx. 400Gb of data. I did see the free backup space indication go up correspondingly once, but after the next backup I was down again to only 7% available space (858Gb used instead of around 450Gb). That really had me stymied.
The answer to that mystery is given here: http://blog.hawkimedia.com/2012/08/reclaiming-a-timemachine-volumes-disk-space/
In short, you have to compact the sparse bundle that actually holds the backup if it is hosted on a networked disk, or on a disk that is not formatted in HFS+.
I don't have TM backups that are not hosted in a sparse bundle so cannot check if using tmutil delete
does reclaim free on those. It might well do and the fact it doesn't on a Time Capsule may simply be a peculiarity of the sparse bundle protocol.
The command to execute after sudo tmutil delete
is sudo hdiutil compact /Volumes/YourTimeMachineDisk/YourBackupName.sparsebundle
. In my case that reported
Starting to compact…
Reclaiming free space…
...................................................................................................................................
Finishing compaction…
Reclaimed 403.2 GB out of 583.5 GB possible.
The good news is that this command took only a fraction of the time tmutil took, spending much less time seeking on the disk and using less RAM (in fact it completed in the time it took me to write this answer).