Reclaiming drive space by thinning Apple File System snapshot backups
As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.
A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:
tmutil deletelocalsnapshots snapshot-name-here
However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:
The tmutil command line tool on macOS High Sierra includes a thinlocalsnapshots function, which has the options shown below:
tmutil thinlocalsnapshots mount_point [purge_amount] [urgency]
Purge amounts are represented as bytes, so specifying 20 gigabytes of space would be represented by the number below:
21474836480
Urgency levels are 1 through 4, with the default urgency setting being 1.
Urgency level 4
Most urgent: Any current backup processes are stopped and thinning is performed immediately. The largest available backup will be the first thinned, with thinning proceeding through the next largest backups.
Urgency level 1
Least urgent: Current backup processes will be completed before the thinning process begins. The oldest available backup will be thinned first, with thinning proceeding through the next oldest backups.
To free up 20 gigabytes of space from the snapshots stored on the boot drive at maximum urgency, you would use the command shown below:
tmutil thinlocalsnapshots / 21474836480 4
The command may take a while to run, depending on what would need to be done to free up the requested space.
Note: The thinning process may actually free up more than the requested space, but it should free up the requested space as a minimum if the stored snapshots are taking up at least that amount of drive space.
Before snapshot thinning
Snapshot thinning
After snapshot thinning
Leave a Reply
Recent Comments
 | rtrouton on Creating a NexThink installer… |
 | this is not the Pete… on Creating a NexThink installer… |
 | Shri Sivakumaran on Adding password protection to… |
 | isotopp on Creating a sysdiagnose file us… |
 | Daniel O'Donnell on Apple Device Management Second… |
Der Flounder 
Thanks for the info. I imaged a customers iMac to my MacBook before working on it and stored the 340GB disk image on my MacBook. Got back to the office and copied the image to my backup server and deleted the file. Then I had an issue between Finder and the OS showing different free space numbers and only 8% free under diskutil. Took me a bit to track it down – but it was the local snapshots. I will probably be doing this again some time in the future and it’s frustrating that I cannot turn off local snapshots now – you use to be able to do this.
Is it possible to use this thinning technique (or a similar technique) on sparse bundles created by Server.app?
I’m confused. I’m not an Apple user, but if I think all that ‘thinlocalsnapshots’ command is doing is automatically choosing *which snapshots* to delete? So, your comment, “However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed,” doesn’t seem to make a lot of sense?
Aren’t you still deleting stuff? Either stuff is occupying your disk, or it isn’t. There’s generally not a way of getting free space without deleting something (except for compression, which this does not appear to be)?
So what exactly is being thinned? Can you share the difference between:
…and this:
Seems like it’s important to know what is being thinned…
Alternatively, is there a link you could share that would explain the snapshot function in more detail (possibly including the ‘thinlocalsnapsots’ command)?
@rtrouton, do you not respond to comments/questions on this blog??
Sometimes.
Any chance you might be able to explain what exactly is ‘thinned’ when thinning local snapshots, or share a link to a resource to learn more about the process?
Thanks!
John
All the information I have is available in the blogpost. For more information on this topic, I suggest contacting Apple: https://support.apple.com/HT201232
So you have no idea what exactly gets “thinned” out of a local snapshot, as opposed to deleting the snapshot altogether? I highly doubt Apple support is going to be able to answer that question, but thanks anyway!!
Please forgive my pestering you today. Your blog is an incredible resource, so the last thingI want to do is be critical. The time and energy you have put in to this site, since 2003(!) is unbelievable, and hugely appreciated by all who come here, I’m sure.
THANK YOU!
John
No worries, hopefully you’ll be able to find elsewhere the information that you’re looking for.
I cannot find any direct Apple reference to the exact definition of what thinlocalsnapshots does – but – I can tell you what it usually means to ‘thin’ within backup programs generally.
If you have 5 backups and all of them contain the same file in each backup – when you thin out the backups it creates a new backup from the 5 that you have and makes sure that the new backup only contains each file once. It keeps the most recent version of the file and discards all the other copies of the same file found in each backup. The original 5 backups are deleted on completion.
Thanks
Matt
That’s really helpful, Matt, thanks!
This command saved my day. Apple’s blissful ignorance in admitting APFS related failures is getting to the point of insanity, thank heavens there are people like you saving us from going mad!
Absolutely appreciated. Thank you rtrouton!
APFS is a completely different monster when compared to other disk formats. It’s meant to “save the world”, while accomplishing to destroy people’s data… Try encrypting a whole drive and then decrypting it and you will see what I mean… My photos were all corrupted, along with my music. Thank God for the cloud! I was able to recover the files, but now I have two versions of each file. One with the partially corrupted file and another with the perfect file, downloaded from the cloud. And all duplicate check/delete apps I’ve tried cannot get rid of the corrupted files either, since essentially they are different from the non-corrupted files. I’d totally go back to HFS+ if I could. Unfortunately that’s not an option when running purely SSDs and Mojave…
I use Carbon Copy Cloner to keep a bootable copy of my hard drive as well as use TimeMachine to keep a running archive. I do this when I feel that enough changes warrant doing it. Unfortunately, TimeMachine creates local snapshots when it is run and, it appears that if one exists, any file I delete from then on will be added to the snapshot and, presumably, “kept around” in case I want to recover it (even though I’ve dragged it to the trash and emptied) it. This file just simply grows and is “recognized” by Finder as “purgeable space”. Apple claims at https://support.apple.com/en-us/HT204015 that this practice does not affect “normal” operations. However, when I tried to clone my Mac’s drive, this machine pushed the total amount of files to be copied past a point where CCC ran out of space at the destination drive. For whatever reasons, CCC did not ignore the snapshot file and insisted on including it with the files to be copied. Removing the local snapshot via tmutil, something that can be also be done from within CCC, was the workaround for me. (CCC suggested formatting the target drive as APFS in order to avoid a “penalty” on disk space but this does not address the copying of the snapshots.)