Posted by rcarmo 5 days ago
edit: I use Arq for daily backups, but T.M. for hourly. When T.M. eventually craters its storage, I have robust dailies in the cloud, so no worries.
The problem is them fucking up. Every other popular backup solution that does it does it just fine. And doesn't hide failures silently
As opposed to what? When you need to be able to back up to a drive on your network?
I'm sure you could do the same with cron and rsync, but I can't be bothered.
[1] https://shirt-pocket.com/SuperDuper/SuperDuperDescription.ht...
I could probably setup a calendar appointment to dump a bootable image once a month to an external disk.
Edit: Yeah, the bootable backups have saved me more than once. It's great to just be able to keep working even when the system disk is kaput.
Well as long as Apple hasn’t broken that with an update: https://www.shirtpocket.com/blog/index.php/shadedgrey/youre_...
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.
log stream --predicate 'subsystem == "com.apple.TimeMachine" AND NOT (category == "LogLimits" OR category == "VolumeViewModel")' --info --debug --style compact
man log
man tmutil
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?
There was a time in the past when Time Machine was reliable and well-designed. It made backups into a nice experience that were accessible to everyone.
If your only experience with Time Machine is the modern incarnation with all of the flaws and seemingly missing QA process then I understand how its popularity would be confusing.
1. There was a small, smart team which made time machine in the first place. They did good work. Building time machine required some pretty deep integrations into macos that not many people understood.
2. Years passed. The people who built time machine moved to greener pastures. At google and samsung you mostly get promoted for releasing new products. Not maintaining old ones. I wouldn't be surprised if its the same at apple. Over time, the people who made time machine left and were either replaced by more junior developers. Or weren't really replaced at all.
3. Random changes in the kernel break time machine regularly. Nobody is in charge of noticing breakage, or fixing it. Most people who care (and have the knowledge to fix it) have moved on.
I find things like this so odd from an organisational management perspective. Do companies not realise that features like time machine would have an ongoing maintenance cost? That someone would need to check that time machine still works with every release? Or is it just vibe based management out there? "I guess nobody works on that, and we don't test it. Oops whatever."
I assume many managers resist this temptation, but someone yields with regularity.
… so I’ve been kind of biting my tongue on this thread because “works fine for me” is not interesting or helpful, but: it’s been working great for me since it was introduced in 2007.
Periodically a disk will get flaky or go bad, maybe once every 2-3 years. I’ll erase the drive and start over. I always have two backups running so there’s never danger of being completely unprotected.
I don't doubt the people having Time Machine problems, but they usually seem to involve some unusual setup like a NAS. But for every one person who has a problem and speaks up, I suspect there are hundreds or thousands who are just humming along without a hitch.
(and yeah, I do pray for a "Snow Tahoe," "oops all bug-fixes" MacOS release, and I’d love to hear that there’s a team working not just to make Time Machine more resilient, but to expand it to do local backups of iPhones and iPads… a guy can dream)
> … so I’ve been kind of biting my tongue on this thread because “works fine for me” is not interesting or helpful, but: it’s been working great for me since it was introduced in 2007.
Is immediately contradicted by this
> Periodically a disk will get flaky or go bad, maybe once every 2-3 years. I’ll erase the drive and start over. I always have two backups running so there’s never danger of being completely unprotected.
Having to periodically erase the drive and start over is one of the problems we’re talking about.
In my experience, restoring files gets flakey before it reaches the point of having obvious backup failures so you may be experience more problems than you know about if this is happening periodically.
I have since implemented a borg backup. This also failed at one point, but at least its five-year record remained readable, so no data was lost. Now I'm using restic.
It has its flaws, but any system is better than no system at all, which is usually the trade off that would be made.
That's why I like it. Some of the visual flare is of course superfluous, but the timeline really is nice.
It's like git except it works without me having to think about it. (To be clear, git is much better, but I have to think about it.)
Also, backups over the network are possible and have worked well for me for a few years.
From what I can tell, this snapshot is preventing space reclamation. The last month or so, I've constantly run out of disk space even when not doing anything special. As in actually run out of disk space — apps start to become unresponsive or crash, and I get warning boxes about low disk space. When you run low, the OS is supposed to reclaim the space used by snapshots, but I guess it doesn't happen,
The stuck snapshot can't be deleted with tmutil. I get a generic "failed to delete" error. The snapshot is actually mounted by the backup daemon, but unmount also fails. The only solution I've found is to reboot. Then I get 200-300GB back and the cycle starts again, with snapshots getting stuck again.
I'm considering updating to Tahoe just because there's a chance they fixed it in that release.
I think I have the same problem on Tahoe.
On the extremely rare occasion I have to replace my laptop, I literally just point it to the backup on the network with the cable plugged in, and an hour later it's "my laptop" again.
But, I haven't installed Tahoe. I may skip it entirely, hoping that they do a Snow Leopard-like clean-up-the-mess release in September.
Apple really needs to turn things around.
Yosemite > El Capitan > High Sierra > Big Sur > Ventura > Sequoia
I won't be installing Tahoe for the time being. Hoping macOS 27 will be an improvement.
Something like [1] can be inspiration.
If I had to start over I'd go with rustic-rs or borg backup.
FWIW I do still use `tmutil localsnapshot` for local macOS snapshots where you can use the Time Machine UI to restore files.
It's the same on macOS and iOS, pick "macOS Sequoia Public Beta" or the corresponding release for your device. Apple still pushes security updates for those releases, and I haven't heard of any problems with the kind of minor updates that ship late in a major release's lifecycle, so I think the risk of running this way is low. This kicks the can a year or two down the road, at which point hopefully there are better workarounds.
Apple should document such changes, but, looking at the post title, you'd think they were silently corrupting data during restoration.
I'd argue that's not even the main problem. If it just broke and gave you error on each run ("this SMB share is incompatible") it wouldn't be an issue
> Time Machine backup to NAS devices over Apple Filing Protocol (AFP) is not recommended and won't be supported in a future version of macOS.