The only way to run 32-bit Mac apps in Catalina is in a Virtual Machine (VM), which probably makes virtualisation more popular in 10.15 than any previous release of macOS. Unfortunately, VMs are well-known for causing problems with Time Machine backups, as are any large and monolithic files. This article looks at what you can do to make your backups smaller, quicker and simpler with such large files.
Virtualisation software such as Parallels Desktop and VMware Fusion stores its VMs in single files which often grow exceedingly large. Even a minimal installation of Mojave in Parallels, for example, requires a 6 GB disk image, and large and active Windows VMs can readily grow to tens and hundreds of GB.
Because these are single file disk images, rather than bundles of many smaller files, there only has to be a single byte changed in them for Time Machine to have to back the entire file up all over again. This adds considerably to the amount which needs to be backed up every hour with relatively little benefit to the user. It also increases the requirement for space on the backup volume, and the rate at which that is consumed.
Add all large files such as VMs and databases to the Time Machine exclude list. This is readily done in the Time Machine pane.
However, if you try that, you’ll discover that it only solves part of the problem.
What isn’t apparent is that VMs and other very large files have another hidden effect on backups which can’t be solved by adding them to its exclude list. In High Sierra and later, each time that Time Machine backs up any part of an APFS volume, a snapshot is made of the whole of that volume. The snapshot consists of a copy of the whole file system metadata – directories and everything else – for that volume, and from then on until that snapshot is deleted, as files change, their previous data is retained. This allows you to restore that volume to its exact state when that snapshot was made.
Snapshots are more efficient than regular backups. If a single byte changes in a file, the whole of that file has to be copied in the next backup. Snapshots keep only the parts of the file that change, so that the original can be reconstructed. But over time and use of that file, the amount of it which has to be retained to restore its original state inevitably rises up to the limit of the whole file size.
Snapshots can only be performed on whole APFS volumes at a time. When Time Machine backs up any part of a volume, even just a single file from it, it makes a snapshot of the whole volume, which includes changes made to every other file on that volume even when they’re excluded from the backup. It also doesn’t provide any easy means for you to see the effective size of its snapshots, nor is there any way to disable them in Time Machine backups.
The relevance of snapshots to VM and other large files is that, even when you put them in the exclude list, if the volume containing them is being backed up, they will still be included in its snapshots.
To inspect snapshots, you can use
tmutil, which I have detailed here, or Carbon Copy Cloner, which can also make its own snapshots. If you use Carbon Copy Cloner’s snapshot feature on a volume containing a VM or other large file, you should check the amount of space in that volume being taken up by those snapshots and delete them as necessary. You may find it worth changing its snapshot policy to keep them under control – something you can’t do with Time Machine, though.
Solution: Exclusion from snapshots
If you have sufficient free disk space to include VM and other large files in backups and snapshots, then you don’t need to change their location or policies.
To maintain better control of backup storage, you should move VMs and other large files to a separate volume, and add the whole volume to the Time Machine exclude list, or disable snapshots on that volume in Carbon Copy Cloner.
Create a new volume on your chosen disk using Disk Utility. As APFS volumes share space in the same APFS container, this new volume can be within the same APFS container as the volume on which they have been stored. Move the VMs and large files to that new volume, then add the whole volume to your Time Machine exclude list. It will then not be backed up every hour as it was before, and that volume won’t have snapshots made of it either. You will still, though, need to back that new volume up, perhaps daily using Carbon Copy Cloner, SuperDuper! or a regular backup utility.
Postscript: So how should you back up VMs?
The above discussion is primarily concerned with how to avoid VMs (and other very large files) causing problems when backing up other files using Time Machine. Backing up VMs is a different issue, of course. If the VM has to be kept running, then simply making a copy of it isn’t going to result in a restorable copy because of the changes which will take place within the VM while that backup is being made. Other solutions, like Vimalin, are then necessary. For the occasional user of VMs, who can make a daily copy of their inactive VM during the night, for example, this shouldn’t be necessary.
If you want to learn more about how to back up VMs, then the comments below contain valuable information from users who really do know what they’re talking about. I’m very grateful to them for the advice they have provided.