0

I have an issue with Time Machine on macOS Catalina 10.15.6 (and earlier versions of Catalina) that prevents it from properly deleting backups to free up space.

I am backing up to a FreeBSD server that uses ZFS over Samba. I have also tested using netatalk but saw the same behaviour.

The time machine UI and the tmutil listbackups command correctly show backups being deleted but doing ls shows several folders from backups that do not appear in the the Time machine UI. These orphaned backups don't present a problem until the Time Machine destination runs out of space and is unable to delete backups to free up space. At this point my options are to manually delete the orphaned backups from the destination with the tmutil delete command or delete the entire backup and start again. I did the latter recently.

Additionally the orphaned backups only list the following files:

Macintosh HD - Data/ 
Recovery/

The real backups also how the Macintosh HD folder

For example here is the output of of tmutil listbackups:

$ tmutil listbackups
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-13-103401
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-14-092431
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-15-072542
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-16-083106
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-17-064110
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-18-050256
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-035834
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-131107
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-140703
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-155926
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-170643
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-185950
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-200052
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-205831
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-215711
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-19-232248
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-005651
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-015636
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-025627
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-035707
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-045717
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-055647
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-065643
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-080414
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-090434
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-100453
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-110119
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-121634
/Volumes/Time Machine Backups/Backups.backupdb/HAL-9000/2020-07-20-130330

While here is the output of ls in the backup destination:

$ ls /Volumes/Time\ Machine\ Backups/Backups.backupdb/HAL-9000 
2020-07-13-103401/
2020-07-13-171911/
2020-07-13-181839/
2020-07-13-191923/
2020-07-13-202839/
2020-07-14-092431/
2020-07-14-142445/
2020-07-14-220404/
2020-07-14-233839/
2020-07-15-033055/
2020-07-15-072542/
2020-07-15-102644/
2020-07-15-113355/
2020-07-15-122717/
2020-07-15-165108/
2020-07-16-083106/
2020-07-16-094313/
2020-07-16-114045/
2020-07-16-131217/
2020-07-16-164541/
2020-07-16-175441/
2020-07-16-213731/
2020-07-17-064110/
2020-07-17-140709/
2020-07-18-000320/
2020-07-18-050256/
2020-07-18-133030/
2020-07-19-035834/
2020-07-19-131107/
2020-07-19-140703/
2020-07-19-155926/
2020-07-19-170643/
2020-07-19-185950/
2020-07-19-200052/
2020-07-19-205831/
2020-07-19-215711/
2020-07-19-232248/
2020-07-20-005651/
2020-07-20-015636/
2020-07-20-025627/
2020-07-20-035707/
2020-07-20-045717/
2020-07-20-055647/
2020-07-20-065643/
2020-07-20-080414/
2020-07-20-090434/
2020-07-20-100453/
2020-07-20-110119/
2020-07-20-121634/
2020-07-20-130330/
Latest@

Notice the extra orphaned backups in the ls command. What is strange is that some backups are properly deleted. For example on most days backups are done hourly, and most are properly deleted. Only a few backups each day become orphaned. Those orphans can be deleted with the tmutil delete command but Time Machine shouldn't be producing any orphaned backups.

I have no idea why Time Machine is not properly deleting backups.

Edit: I have now tested this on a HSF+ formatted USB external hard drive and observed the same behaviour.

4
  • 1
    The expected deletions are (or should be) occurring due to TM's own thinning, or manual deletion? – benwiggy Jul 20 '20 at 21:23
  • 1
    It sounds like @ScruffyDan may have found a bug (not surprised). If those orphaned backups have any content I would think they are symlinked to but if they are indeed empty(?)... – Steve Chambers Jul 20 '20 at 21:37
  • @SteveChambers The orphaned backups do indeed a bunch of content. This is what causes the issues when the destination fills up. – ScruffyDan Jul 20 '20 at 22:30
  • @benwiggy The deletions should be occurring automatically. all be one backup on any given day should be deleted after 24 hours. – ScruffyDan Jul 20 '20 at 22:31

You must log in to answer this question.

Browse other questions tagged .