Comment by btreesOfSpring | Hacker News Reader

Comment by btreesOfSpring | Hacker News Reader

I have been trying to trouble shoot a Time Machine issue since upgrading to Tahoe. It is usb backup. So far none of the most recent stated fixes work.

An initial backup on newly formatted disk will run but very slowly. Perhaps reaching 100% but it never finishes. At some point the percentage will change and the backup will stay stuck at somewhere near 10%. Cancel backup and run it again. Gets to ~10% and stays stuck. Multiple drives. Re-fs'ed. Boot into safe mode. Networking off. Etc, etc. etc. The TimeMachineMechanic app doesn't have any revealing feedback. I can run a full tar backup to the same disks.

No idea.

I haven't tried backing up to a network share but really, it shouldn't be this difficult.

Clearly someone didn't test a bunch of edge cases when pushing this one out.

In a terminal window run

  log stream --predicate 'subsystem == "com.apple.TimeMachine" AND NOT (category == "LogLimits" OR category == "VolumeViewModel")' --info --debug --style compact

and then start a backup (either from the menu bar icon, the system settings panel, or "tmutil startbackup"). This will tell you what Time Machine is doing, and might give you some useful information.

  man log

where you can use "show" and a lookback period instead of "stream".

  man tmutil

is pretty decent documentation, although the glossary secdtion ("BACKUP STRUCTURE") is important to understand if reading the whole man page.

Some things to look out for are what filesystem your newly formatted external volume is (APFS might not be great for a single spinny disk, for example), and what version of USB is in use (friends don't let friends do USB 2 mass storage). With inexpensive external media it's often a cable or power supply issue, even if (as in your case) tar appears to work. Have you checked that the contents of the tar file are correct? Also, tar files tend to be streamed out to sequential LBAs, where smaller files and (in Time Machine backups) holes might lead to a different write pattern that the drive might not like. Maybe test with rsync -c instead of tar?

Reply on news.ycombinator.com