1

Have MacA and MacB running TM and backing up to the same Time Capsule. TC has the internal drive and two attached USB drives - same problem occurs on all of them. Both Macs are latest version - 10.15.7, and TC is the terminal version 7.9.1

MacB will frequently show a "Failed to eject diskX" message in the log. Then cannot mount that sparsebundle on MacA. This will continue even after complete power down and restart of everything - MacA, MacB, the TC, and the external drives - so some setting must be persisted to one of the drives, but what and where? If MacB is offline for a couple of days (wife's computer and not heavily used), and MacA has gone through a couple of daily power cycles, then suddenly all of the bundles can be mounted. When MacB is turned on again, and generates some new backups, then the same problem recurs.

Have reported to Apple feedback with full discussion and logs https://feedbackassistant.apple.com/feedback/7739401 but so far crickets.

Will sometimes (rarely) have the same problem with a sparsebundle for a MacA backup also not being mountable on MacA - this usually clears after one reboot. Note that the remount issue occurs when trying to use Finder, or from the command line with hdiutil or open (using DiskImageMounter internally) - usually get a "Resource temporarily unavailable" message. Time Machine itself never seems to have any problem re-mounting these bundles for the next backup.

Suspect some XATTR setting, but various experiments have all failed.

Any suggestions? Thanks

Improve this question

1 Answer 1

Reset to default
0

You may not like my advice, but walk away from network backups. Use direct attached storage and use two backup destinations if you can’t afford to have one take days to check the filesystem if they eject due to a cable failure, power failure or cat.

To have things run as you describe, you’d need dedicated new hardware, have to set up a directory service and/or managing permissions by user ID, manage SMB and possibly AFP sharing services, the source system has to do a ton of overhead to manage the storage bands. Time Capsule is not powerful enough for the task in my experience. It was fine 5 years ago (fine for light use, OK performance) but not anymore.

What’s easy is APFS filesystem on the Mac so your get snapshots and HFS+ filesystem on the storage destination.

And to answer your question, you can use tmutil stopbackup to ask for a quick abort, but since you skip any clean up, your next backup interval takes so much longer since the code has to do all the cleanup before it finishes the next interval. I would need to analyze the network capture, but temporary unavailable errors can be due to the server not responding in a timely manner since it’s busy managing files and network as opposed to serving the data to your Mac.

Improve this answer
6
  • Thanks for your response, and agree with your point. The situation is though that I'm trying to write a general purpose utility which will analyze TM backups (running in the background), and be able to display them to the user - with, among other items, the name of the backups, how much space used, how long each backup took, etc. For this to be released for general use it must support all configurations - directly attached drives, NAS drives, and Time Capsule. Direct drives are already tested and fine, but cannot get past this TC issue - which has stopped the whole project.
    – JDC
    Commented Oct 4, 2020 at 15:27
  • Yeah - it’s been a long time since I put my tool of choice against a time capsule. BackupLoupe does the best job for me and DaisyDisk is the best for analyzing the source. You could demote the Time Capsule to bridge mode, make it not the network router to give the CPU all resources to serve the sparse disk bundles. @JDC hit me up in chat if you ever need a tester on your app.
    – bmike ♦
    Commented Oct 4, 2020 at 15:49
  • 1
    Would love to have you test. How do I get to you in chat?
    – JDC
    Commented Oct 4, 2020 at 18:00
  • And now that I know you’re crawling all the backups - that’s going to be super hard to do patiently from Java, but just because it’s hard or against the odds, some program could be clever enough to pull this off.
    – bmike ♦
    Commented Oct 4, 2020 at 19:36
  • Yes, but started as my own curiosity because some backups seemed way too large. Launches a background task to do the crawling and builds a local cache of results, so it's "fire and forget" for the user and all the results available for viewing instantly. Cut my own backups from a 300-400M range to 30-40M per (TM was backing up a lot of caches and test directories that really did not need to be backed up).
    – JDC
    Commented Oct 5, 2020 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .