If you use Time Machine you’ll be aware that its backups don’t contain everything that they could. One obvious example is that, at least when backing up to APFS in Big Sur and later, you can’t back up your System volume any more. This article looks at what is and isn’t backed up by Time Machine in recent versions of macOS, in particular in backups made to APFS. If you want to read about Mojave and earlier, this article should help.
Time Machine has several mechanisms by which items are designated as not to be backed up.
The first of those exclusion mechanisms used to be its Standard Exclusions list, at /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist, but that disappeared without trace in Big Sur. Currently the only way to inspect that list is by locating the hidden file .exclusions.plist at the top level of any backup.
This lists several categories of exclusions, of which the first are apiExclusionPaths, which are added by individual third-party apps. The equivalent of what used to appear in StdExclusions.plist is now given under the standardExclusionPaths key, which contains:
- .DocumentRevisions-V100 – the version database on each volume, added in Big Sur,
- .Spotlight-V100 – Spotlight metadata,
- .Trashes – contents of Trash folders,
- .fseventsd – the File System Events database,
- /Library/Logs – traditional text log files,
- /Users/Guest – guest user files,
- /private/var (partial) – various transient files,
among other ephemeral items.
Of those, only one results in any significant loss of data, the version database. Although this was dutifully copied by Time Machine into backups for several years, the current structure of that database appears to make it impossible to restore successfully, even when restoring a complete volume. By the middle of the Catalina cycle, it had become a frequent cause of Time Machine choking, so was added to the standardExclusionPaths for Big Sur. As far as I’m aware, though, this was never fixed in Catalina.
Following those are stickyExclusionPaths, which exclude various photos library contents in Big Sur. This has expanded considerably in Monterey to include language modelling files and more. The key systemFilesExcluded is set to true to ensure that the whole System volume is always excluded, following which are any userExclusionPaths which you have set using
tmutil or in the Time Machine pane, as explained here.
Per-item custom exclusions
In addition to the rules given in the Standard Exclusion list, any file or folder can have an extended attribute of type
com.apple.metadata:com_apple_backup_excludeItem attached to it as a ‘sticky’ exclusion, which may add it to the stickyExclusionPaths list and prevents it from being backed up by Time Machine. If you then remove that extended attribute, it should be backed up normally again.
Items stored in iCloud are a more complex problem. The rule here seems to be that Time Machine does back up the contents of your current iCloud Drive, but only those items which are currently stored locally. Any items which have been evicted to iCloud, and are only represented by local stub files, aren’t backed up.
There’s a sound rationale for this, although I can’t recall it being explained by Apple. Quite a few users now have a great many files evicted to their iCloud Drives, far more than they could store locally. This is perhaps most common among those who work with their Desktop & Documents folders in iCloud. For Time Machine to be able to back up a file evicted to iCloud Drive, that file would need to be downloaded to local storage first. Imagine having a 512 GB internal SSD, and over a terabyte of documents in your iCloud Drive, almost all of which were evicted from local storage. Even if Time Machine were to download these in rotation so as not to exceed local space available, how long might it take to perform that for a backup?
iCloud Drive files which are already in local storage are fair game, though, and as far as I can tell, that’s all you’ll get in your Time Machine backup. So if you want a document backed up locally, and its iCloud icon shows it to have been evicted, select it and ensure that it downloads before a backup is made. You may find my free app Cirrus or its lightweight sibling Bailiff a help with that.
Photos libraries are something of an oddity here, as it has been known for several years that Time Machine doesn’t back up some of the folders inside Photos libraries, although for some time this was considered to be a bug.
Apple’s advice on backing up Photos libraries is to either use Time Machine, or make a manual copy of the library to external storage, although only the latter will replicate your library in full. When Time Machine backs up a Photos library, it completely omits the database folder within it because it has an extended attribute of type
com.apple.metadata:com_apple_backup_excludeItem. This assumes that the contents of that folder can be successfully regenerated by Photos after a library has been restored from backup.
Carbon Copy Cloner
Mike Bombich gives a thorough and detailed account of what CCC doesn’t copy on this page. As far as I can see, his list is essentially the same as Time Machine’s standardExclusionPaths.