Ventura Time Machine Backups and the APFS Uncertainty Principle
Before making any snapshots for this backup, TMA performs housekeeping on its own previous snapshots, both on each volume being backed up, and on the target volume (backup storage). The rule it applies is inflexible: it deletes any local snapshots (on a volume being backed up) that are more than 24 hours old, unless it’s the last snapshot on that volume, which it retains for this backup. Even so, TMA snapshots can become orphaned and left indefinitely, for the user to spot and delete manually. Although uncommon, this can occur when Macs are unable to make full backups because they’re disconnected from their backup storage for more than 24 hours at a time.
[…]
TMA next has the task of deciding how it’s going to work out what needs to be backed up on each source volume. […] Snapshot deltas were first choice in the past, but TMA has returned to preferring FSEvents when possible, for second and subsequent backups of a volume.
I wonder whether this is for performance reasons.
If the large files you put in the Trash were on the volume being backed up when Time Machine made one of those hourly snapshots, then the data for those files will be retained as part of that snapshot, until the last snapshot containing those files is deleted. Only then can the data for those files be removed, and the space they took up will be freed.
[…]
The cleanest way to avoid this happening is to keep all downloads and large temporary files on a separate volume which isn’t backed up, so doesn’t have snapshots made of it automatically.
[…]
If you don’t want to use a BigFiles volume, or can’t select where to save a large temporary file, you can work around snapshots by timing. Before acquiring that large file, check when the last Time Machine backup was made, using the Time Machine item in the menu bar. Provided there’s sufficient time before the next backup is due, you can download the large file(s), move them to another disk for storage or otherwise use them, then put them in the Trash. But the most essential step is that you must then empty the Trash before the next backup starts, or they’ll be captured in the next automatic snapshot.
I’ve been pondering just how difficult—perhaps impossible—it is to know how much free space you actually have on a Mac’s drive these days (see “Ensure Sufficient Free Space before Upgrading to Ventura,” 15 November 2022 and “iPhones and iPads Now Require a Passcode on Every Backup/Sync,” 11 January 2023). The complexity underlying APFS and macOS in general creates a situation where the amount of free space isn’t entirely deterministic.
[…]
I figured that if I emptied the Trash, I’d either see no change due to the Time Machine snapshot issue or have almost exactly 145 GB free. Surprisingly, neither was true. After a minute or so, the free space number did rise—as expected—but first to 148 GB (not shown) before settling down at 146 GB. I can’t explain why it was a full gigabyte higher than would seem possible.
[…]
Grasping at straws, I decided to restart, just in case that somehow helped the filesystem come to a better conclusion about the amount of free space. Unfortunately, after my Mac came back up (with the same apps running), the free space number had dropped to 159 GB.
[…]
I no longer believe it’s possible to audit the free space on a Mac or to explain precisely how much space should be freed up by a particular action.
Previously:
- What Happened to Virtual Memory?
- Time Machine Evolution and APFS
- Big Sur Really Needs Real Free Space
- Quantum Computing and APFS: Free and Used Space
10 Comments RSS · Twitter · Mastodon
> I wonder whether this is for performance reasons.
I suspect this is because snapshot delta are block based and can't properly handle backup exclusions. It is hard to know which block of the delta should be backup, and which don't, as any file can be marked as excluded from Time Machine.
@Jean-Daniel Are you agreeing with me (because each block would need to be mapped back to a file before exclusion testing, instead of with FSEvents where you can easily ignore changes for a whole folder) or making a different point?
As time has gone on, I'm starting to question whether APFS is a good idea or worth it. By and large it doesn't seem to offer me the user anything particularly useful. To me it seems like everything works more or less the same as it did with HFS+, but worse. Now I can't do things like modify system files even with SIP disabled, assume which volume a file is on, figure out how much free space I have, and easily free up space without resorting to the command line. On top of that, it's buggy. I've seen the ostensibly invisible seams between the system and data volume become apparent more than once.
HFS+ also had the advantage that, no matter what was going wrong with it, I could run the volume through DiskWarrior and magically fix it. That advantage might soon be shared by APFS, but only time will tell.
The one thing I like about APFS is that I can create a single container volume and then install Catalina and up into it and have them all share drive space. That's pretty nice. But it doesn't seem worth it, frankly.
@Bri I’m convinced that it’s worse for spinning hard drives. The read/write performance is awful, and drives no longer mount automatically/promptly. But I use APFS because encrypted HFS+ is no longer directly supported. And because, in theory, snapshots may someday save data for me, though in practice so far every failure that lost data also lost it from previous snapshots.
@Bri How is it going for you with installing different macOS versions in different APFS containers on the same disk partition? I've tried that in the past and it didn't go so well because, at least at that time, if different macOS versions were using the same files in, say /usr or /bin, those files were not duplicated but referenced by all containers. It happened to me that updating macOS on one of the containers would destabilize and sometimes screw up macOS from one of the other containers. From that time on, I only use containers to share partition space between one macOS version and data that I want to make accessible to other partitions. And I partition my drives to explicitly separate different macOS versions that I want to host on the same drive.
@Michael I have personal experience that APFS considerably slowed down the Fusion drive of my iMac and my clients' iMac too. Cloning the internal drive onto an external SSD completely solved the issue in all the cases I was faced with. PS: You mentioned the speed penalty of APFS on spinning hard drives back in 2019: https://mjtsai.com/blog/2019/09/19/apfs-enumeration-performance-on-rotational-hard-drives/
@Bri I dunno. Sparse VM disk images that are also "flat", backups of those images that are consistent due to snapshots, near-instant duplication of directory hierarchies with clones. It's not all bad, is it? But you're right about where it falls down, especially the not-quite-a-benefit of the sealed system and the supposed gains in update efficiency. Now that's a whole vat load of snake oil if ever I saw one.
@Damien I haven't had any major issues with running multiple macOS versions from the same volume. But I don't boot most of those systems very often. I have them all installed on a single drive for testing. So I don't use them extensively. At least so far I haven't had any problems caused by updates.
I don't think they share files between different macOS versions, though. Each system volume and data volume have their own partition in the container. They just all share the same space.
@Damien: The APFS containers are just like partitions except you don't need to choose a fixed size. Instead the storage amount in shared. But the contents are not shared.
@Bri & @Alexander Thanks a lot for your feedback. It must have been another reason why I had issues with multiple macOS versions installed in different volumes of the same APFS container then.
Your answers prompted me to dig a bit deeper and my research showed me that in addition to the typical 'Macintosh HD' and 'Macintosh HD - Data' volumes, there are three hidden volumes called 'Preboot', 'Recovery' and 'VM'.
An issue might have arisen with an overwrite of one of those three hidden volumes, I guess.
@Bri May I ask you to check if multiple 'Reboot', 'Recovery' and 'VM' volumes have been created within the container that has all your different macOS versions? You'll be able to check that using Terminal and the command 'diskutil list'.
