"Time Machine must erase your existing backup history and start a new backup to correct this." Why is that?

Question

I seen this message for the past two days:

"Time Machine detected that your backups on “SynologyDS216.local” cannot be reliably restored."

"Time Machine must erase your existing backup history and start a new backup to correct this."

I can access the backup history just fine. The NAS (which have RAID 1) is fine as well.

When I look at the backups:

~ ᐅ tmutil listbackups | tail -n 5
2020-10-15-144522
2020-10-15-151447
2020-10-15-154125
2020-10-15-184439
2020-10-15-195406

We can see that it stopped doing backups exactly 2 days ago, so I decided to do a check:

tmutil verifychecksums /Volumes/Time\ Machine\ Backups/Backups.backupdb/Thomas-MBP

and an error that popped up is:

/Volumes/Time Machine Backups/Backups.backupdb/Thomas-MBP/2020-07-08-200220/Macintosh HD/System/Library/DirectoryServices/DefaultLocalDB/Default: error 257 enumerating path

The directory exists:

total 0
drwxr-xr-x@ 3 root  wheel   102B Aug 25  2019 .
drwxr-xr-x@ 5 root  wheel   170B Sep 29  2019 ..
drwx------+ 7 root  wheel   238B Aug 25  2019 Default

but the permissions are an issue. This file has extended attributes, so I look to see what's up:

/Volumes/Time Machine Backups/Backups.backupdb/Thomas-MBP/2020-07-08-200220/Macintosh HD/System/Library/DirectoryServices/DefaultLocalDB ᐅ sudo ls -le Default
total 0
drwx------@ 2 root  wheel   340 Aug 25  2019 aliases
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel   102 Aug 25  2019 computers
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel  4420 Aug 25  2019 groups
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel   102 Aug 25  2019 networks
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwx------@ 2 root  wheel  3468 Aug 25  2019 users
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

When looking on the host machine:

/System/Library/DirectoryServices/DefaultLocalDB ᐅ ls -l

    total 0
    drwxr-xr-x  3 root  wheel    96B Jan  1  2020 .
    drwxr-xr-x  5 root  wheel   160B Jan  1  2020 ..
    drwx------  7 root  wheel   224B Jan  1  2020 Default

the permissions are not the same and the data can be accessed.

It looks like TimeMachine claims it can't use the backup due to some permission issues...

I tried to ask about it on the Apple forums but my post got removed because I'm running a beta version of the OS...

Has anyone seen this problem before?

Answer 1

“Has anyone seen this problem before?”

I have, and from what I have heard from reading forums over the years, it sounds like a very common problem with Time Machine: every once in awhile, it says “I need to delete your backup and start over.”

Or it says “I can’t backup because your backup device is full” (even though Time Machine is supposed to prune itself as needed).

Or something else comes up that causes Time Machine to choke.¹

Howard Oakley has cataloged a long list of issues with Time Machine, and even has some free apps to help work with Time Machine archives (unfortunately, nothing that can “repair” a “damaged” Time Machine backup, as far as I know).

In response to this I have developed the following attitude towards Time Machine:

1. Never rely on Time Machine as your only backup.

2. Use Time Machine to multiple locations (e.g. a Time Capsule or other remote Mac plus a local Mac) with the expectation that if one gets corrupted, you will still have the other one. Note that Point #1 still stands, even with Point #2

3. In addition to Time Machine, also use at least one (preferably two) of:

• Backblaze
• Carbon Copy Cloner
• SuperDuper
• Arq

---

¹ This is usually where someone will chime in and state that they have used Time Machine since it was first released and never had a problem with it. I do not doubt that there are some people who have had that experience, but I tend to consider them sort of like people who win the lottery: I am happy for them, but I would never expect to be one of them, and have decided to assume I never will be. YMMV.

Answer 2

This happens for a simple reason. Network errors get flagged as hard drive errors, making NAS destinations too fragile for use. Don’t waste your time on any NAS that says they support Time Machine unless you can get them to actually support you when you get errors like this. When you call them, they will point their finger at Apple and Apple doesn’t support Time Machine to anything but a physical drive now.

Apple built in a failure detection mechanism and when you have too many minor errors, any drive is flagged as unreliable for adding new backup intervals and you are forced to make a decision.

1. Keep the drive in read-only mode. The data there is fine for a restore, but no new backups can happen. Put it on the shelf in case you have to restore data from when it has data, but put a new drive in the rotation to do new backups.
2. Erase the drive to start a clean slate. You lose the history, but you can then see if the drive passes the tests and can store new data safely and reliably.

If you must back up to NAS for reasons, also back up to an attached drive occasionally so when the NAS fails you, you can erase it and start fresh.

Answer 3

I've run into this issue a few times now. Today once again. I'm fed up with it and I'm trying out a fallback system:

I often notice the failure within a few days. So now I've decided to setup a backup schedule of my timemachine folder in Synology with HyperBackup. The retention policy is set to 60 days.

Next time Timemachine shows me the finger, I will just get in DSM and restore my timemachine data to the day of the last successful backup. It should theoretically continue again.

This time I'm late, so got to reset the timemachine state.

Fingers crossed.