TimeMachine is a great program for doing automatic system backups, especially since it’s built-in to OS X and easy to use. I had to upgrade from 10.14 to 10.15 some time ago and the newer version is less stable, and also TimeMachine is now buggy. Specifically it now frequently fails to cleanup backups saying this in the logs:
12345678910
2020-11-20 11:01:34.467927+0200 localhost backupd[21553]: (TimeMachine) [com.apple.TimeMachine:BackupThinning] Thinning 3 backups using age-based thinning, expected free space: 546.35 GB actual free space: 5
46.35 GB trigger 49.94 GB thin 83.24 GB dates: (
"2020-11-18-205528",
"2020-11-19-084150",
"2020-11-19-093918"
)
2020-11-20 11:01:40.104450+0200 localhost backupd[21553]: (TimeMachine) [com.apple.TimeMachine:General] Failed to thin backup named: 2020-11-18-205528 completion date: 2020-11-18 18:55:28 +0000 error: Error
Domain=NSCocoaErrorDomain Code=513 "“2020-11-18-205528” couldn’t be removed because you don’t have permission to access it." UserInfo={NSUserStringVariant=(
Remove
), NSFilePath=/Volumes/backups/Backups.backupdb/mymac/2020-11-18-205528, NSUnderlyingError=0x7f97425bd970 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
I couldn’t find anything online about this issue and have no idea why it can’t remove some backups, even when other backups on the same day can be removed without issues. This post recommended restarting backups from scratch after upgrading to OS X 10.15. As we know, “the official way” of copying TimeMachine backups to another disk is broken. So I had to reformat my backup disk to create a fresh encrypted journaled HFS+ partition for the backups, losing all the previous history. Well, it didn’t help fully; maybe the percentage of errors is lower now, but it’s still not zero!
You can see that these backups are not in the output of tmutil listbackups, their directories are still present in the “machine directory” /Volumes/backups/Backups.backupdb/mymac/ and they don’t contain any of the TimeMachine’s metadata files:
123456789
# incorrect backup directory$ ls -a /Volumes/backups/Backups.backupdb/mymac/2020-11-18-104316
./ ../ MacintoshHD-Data/ Recovery/
# correct backup directory$ ls -a /Volumes/backups/Backups.backupdb/mymac/2020-11-18-122641
./ .Backup.log .EventTree.627386399.775371 .exclusions.plist
../ .E7CC5FBF-88D3-4DCA-92BA-FFFFFEEEEEEA.clonedb .EventTree.627386402.617282 MacintoshHD/
.AABBCCDD-BDD6-4391-B9AC-FFFFFEEEEEEA.clonedb .E7CC5FBF-88D3-4DCA-92BA-FFFFFEEEEEEA.eventdb .F986DFE7-AAFE-4565-8F3D-FFFFFEEEEEEA.eventdb MacintoshHD-Data/
.AABBCCDD-BDD6-4391-B9AC-FFFFFEEEEEEA.eventdb .EventTree.627386024.581128 .com.apple.TMCheckpoint Recovery/
The only thing I could come up with so far is to list the “stray” directories and remove them manually. Note: the filename expansion features used in the commands below are from zsh and won’t work in bash (I recommend this post and also man zshexpn to learn these very useful zsh tricks):
The expression *[[:digit:]](/e:'[[ ! -e ${REPLY}/.com.apple.TMCheckpoint ]]':) lists all files ending with a digit *[[:digit:]] (to exclude .inProgress directories) that are directories (/) and don’t have .com.apple.TMCheckpoint in them (e:'[[ ! -e ${REPLY}/.com.apple.TMCheckpoint ]]':). If you don’t have any stray backups, you’ll see this: