Way to keep Time Machine from filling SSD?

[gilby101]

I think the reason is that each snapshot depends on the ones before it, so if you simply delete snapshots you'll mess up those dependencies. [Having said that, I think if you pruned backwards from the most recent snapshots, you'd be OK--but I'm not sure.]

The deletion of APFS snapshots is reliable, unlike those when TM was using HFS+.

Assuming that your disk is not corrupted in some way, you can safely prune TM (and CCC) snapshots from the oldest. But it can take a lot of pruning to gain significant space because most of the files on the oldest backup will still be present in more recent backups.

But before embarking on a pruning exercise, find out when and why you had big increases in size. Disk Utility can help with the when, but I prefer to use BackupLoupe so that I can pinpoint exactly what is causing any increase. [It is slow for the first scan, but keeps its index]

The point is the TM interface is far more functional for doing this than using Finder—because that's precisely what it's designed for.

I have mixed feelings about the TM interface. Mostly I prefer to use Finder. But I can understand its attraction.

 

[theorist9]

The deletion of APFS snapshots is reliable, unlike those when TM was using HFS+.

Assuming that your disk is not corrupted in some way, you can safely prune TM (and CCC) snapshots from the oldest. But it can take a lot of pruning to gain significant space because most of the files on the oldest backup will still be present in more recent backups.

Yeah, plus manual pruining is not really an answer, since the drive will keep filling up.

Having said that, do you have a source indicating manual pruning is safe? I ask because Apple's guidance suggests doing otherwise.

And can you prune in bulk using Finder, i.e., highlight a bunch of snapshots and move them to Trash? Or do you need to prune in Terminal with tmutil? [If the latter, I can understand why Apple's guidance is to just start a new backup drive.]

 

[gilby101]

Having said that, do you have a source indicating manual pruning is safe? I ask because Apple's guidance suggests doing otherwise.

And can you prune in bulk using Finder, i.e., highlight a bunch of snapshots and move them to Trash? Or do you need to prune in Terminal with tmutil? [If the latter, I can understand why Apple's guidance is to just start a new backup drive.]

Personal experience and posts on StackExchange like https://apple.stackexchange.com/questions/407967/how-to-use-tmutil-delete-on-big-sur-apfs

You must not prune in Finder. Use tmutil or Disk Utility. I have always preferred to use tmutil - quick and reliable. Commands like: sudo tmutil delete -d /Volumes/Time\ Machine -t 2020-11-18-100936

 

[Starfia]

I'm fascinated to see so much detailed thought about this, but my instinct is also ask what you think you'll get out of it. The bottom line for you is that you want Time Machine's interface to be as performant as possible when retrieving backed-up files, and you believe you'll noticeably improve that by prohibiting your SSD to become more than a certain percent full?

As a metric, let's take, say, double-clicking on a folder in Time Machine's interface to reveal its backed-up contents. Even if you saw any improvement, would you expect it to be more than, like… hundredths of a second?

 

[ignatius345]

a combination of Time Machine (for versioning) and Carbon Copy Cloner (for backup). My remote archival backup is CCC only—if I lose everything in my home, and have to go to my remote backup, I can live without the TM history.

This is a great strategy! I do the same myself. My CCC offsite is only done once a month to a portable HDD. I also keep everything important synced with iCloud Drive -- so in a home disaster scenario I'd be able to plug any gaps in my CCC backup with files synced in from iCloud.

Currently all my backup drives are still HDDs. I rarely actually need to restore anything, and the lagginess in opening Time Machine from a little portable HDD is totally tolerable to me. Likewise with CCC, I generally let it do its thing overnight when I'm not using the iMac anyway.

I'm sure eventually all this will be SSD-based when prices come down -- but at this time it would cost me many hundreds of dollars to get snappier backups and it's just not worth it to me.

 

[theorist9]

This is a great strategy! I do the same myself. My CCC offsite is only done once a month to a portable HDD. I also keep everything important synced with iCloud Drive -- so in a home disaster scenario I'd be able to plug any gaps in my CCC backup with files synced in from iCloud.

Currently all my backup drives are still HDDs. I rarely actually need to restore anything, and the lagginess in opening Time Machine from a little portable HDD is totally tolerable to me. Likewise with CCC, I generally let it do its thing overnight when I'm not using the iMac anyway.

I'm sure eventually all this will be SSD-based when prices come down -- but at this time it would cost me many hundreds of dollars to get snappier backups and it's just not worth it to me.

I use a pair of cheap HDDs for my archival backups, so that there's one at home and one offsite. Then when I want to update the offsite backup, I just swap them so I don't have to make two trips.

 

[theorist9]

I'm fascinated to see so much detailed thought about this, but my instinct is also ask what you think you'll get out of it. The bottom line for you is that you want Time Machine's interface to be as performant as possible when retrieving backed-up files, and you believe you'll noticeably improve that by prohibiting your SSD to become more than a certain percent full?

As a metric, let's take, say, double-clicking on a folder in Time Machine's interface to reveal its backed-up contents. Even if you saw any improvement, would you expect it to be more than, like… hundredths of a second?

That was the main thing I was thinking of, but I frankly don't know how much performance diff. it will make b/c I haven't done the experiment myself. I know that QLC SSD write speeds can slow to below HDD speeds when you run out of cache, which can happen quickly with some QLC drives when they're nearly full. And that's certainly noticeable. However, what we're talking about here is reads, and I don't know how those would be affected.

But there are other considerations as well--it's generally not considered good drive hygeine to run a nearly-full SSD. There are complexities to these drives that I don't understand (and I suspect most on these forums don't) so, given this unknown, I thought it would be prudent to see if there were a way that to keep TM from filling its allocated space.

Now you could argue that Apple surely must have taken this into account, but you can't blindly rely on that—TM, in particular, has a history of being troublesome, so much so that many recommend *not* relying on it for backup, only versioning (I use CCC for backup). Thus if you have a system that's already a bit finicky, why risk compounding things if you can avoid it?

 

[gilby101]

TM, in particular, has a history of being troublesome

History - yes, if you mean pre Big Sur when backup was to HFS+ drives. Since then, with TM to APFS, the reliability headaches are gone. Still needs to be managed a bit - but every backup strategy does. As you are probably aware, I see little difference between CCC and TM regarding what they do - equally reliable for backup. But nothing wrong with using both.

 

[theorist9]

History - yes, if you mean pre Big Sur when backup was to HFS+ drives. Since then, with TM to APFS, the reliability headaches are gone. Still needs to be managed a bit - but every backup strategy does. As you are probably aware, I see little difference between CCC and TM regarding what they do - equally reliable for backup. But nothing wrong with using both.

I wouldn't be quite so sanguine about TM:

Initial Time Machine Backup Failures Increasingly Being Reported by Mac Users

Apple's built-in Time Machine backup solution for macOS appears to be causing problems for some Mac users running the latest versions of Monterey...

www.macrumors.com

 

[gilby101]

I wouldn't be quite so sanguine about TM:

Initial Time Machine Backup Failures Increasingly Being Reported by Mac Users

Apple's built-in Time Machine backup solution for macOS appears to be causing problems for some Mac users running the latest versions of Monterey...

www.macrumors.com

I think that issue was with 12.1 and some M1 Macs. But pays to be on the lookout for problems whatever the product being used. [I want through the Arq Backup hell with v6 - but all fixed with v7]

 

[Thessman]

There's a couple of utilities like that on the App Store. They only seem to adjust backup scheduling, not the %fill (or space available) at which pruning starts.

Since there's no automatic way to avoid filling the disk (or the partition) used for the TM backup, the best solution is to reduce the amount of backups, by setting TM to backup once or twice per day. I've set it up to backup 3 times a day instead of the default 24!. You could label it prepruning.

 

[wilberforce]

Since there's no automatic way to avoid filling the disk (or the partition) used for the TM backup, the best solution is to reduce the amount of backups, by setting TM to backup once or twice per day. I've set it up to backup 3 times a day instead of the default 24!. You could label it prepruning.

Seeing TM only saves the changes since the last backup, that will not save much space. You are saving 3 bigger backups instead of 24 smaller backups. Also, after a day it only keeps daily changes, so there will be no difference.

 

[theorist9]

Since there's no automatic way to avoid filling the disk (or the partition) used for the TM backup, the best solution is to reduce the amount of backups, by setting TM to backup once or twice per day. I've set it up to backup 3 times a day instead of the default 24!. You could label it prepruning.

To add to @wilberforce 's explanation: As I understand it, the hourly backups are stored internally. Then, once/day, they are combined into a single daily backup and sent to your designated TM storage drive. And there should be no difference between a daily snapshot created based on 24 hourly backups or 3 larger backups, since the daily backup is simply a delta for everything that's changed since the last day. Given that, I'd recommend you go back to hourly backups. That way, if you accidentally trash or change a file, you can go back an hour rather than several hours.

 

[wilberforce]

To add to @wilberforce 's explanation: As I understand it, the hourly backups are stored internally. Then, once/day, they are combined into a single daily backup and sent to your designated TM storage drive. And there should be no difference between a daily snapshot created based on 24 hourly backups or 3 larger backups, since the daily backup is simply a delta for everything that's changed since the last day. Given that, I'd recommend you go back to hourly backups. That way, if you accidentally trash or change a file, you can go back an hour rather than several hours.

Not quite correct, by my understanding and experience. It makes hourly local snapshots which are stored internally, but also makes hourly backups which are stored on the external TM drive.
The hourly backups are combined into daily backups by the TM “cleaning up” process.
Similarly, daily backups are combined into weekly backups after a month.
All of these are incremental backups, in that they only store changes since the last backup, an hour, day, or week ago (as appropriate).

 

[theorist9]

Not quite correct, by my understanding and experience. It makes hourly local snapshots which are stored internally, but also makes hourly backups which are stored on the external TM drive.
The hourly backups are combined into daily backups by the TM “cleaning up” process.
Similarly, daily backups are combined into weekly backups after a month.
All of these are incremental backups, in that they only store changes since the last backup, an hour, day, or week ago (as appropriate).

Ah, I wasn't aware the hourly backups were stored both internally and externally. But, regardless, whether you set TM to do hourly or twice-daily backups, the size of each stored daily snapshot will be the same, correct? The only difference is that, if you do hourly backups, the scratch space for that is going to be somewhat larger than if you do them twice-daily.

 

[ndouglas]

This thread reminds me that my 2 TB backup drive is getting close to, or maybe already past 75%… ugh… time to do something Soon, I dunno what yet…

Realistically when I search my backups for something needed over the years, I always get it from my redundant non-TM backup folders, just easier that way. Still it is nice to keep TM going for peace of mind should I ever need it.