SuperDuper’s “Follow-Up”

Well, no. That's not the "best thing to do"...in fact, I would suggest it's bad advice.

Time Machine is also going to take "a long time" if SuperDuper can't turbo.

For most people, SuperDuper 4 is typically run without the "UI" running. Any time it might take will have virtually no impact on the Mac's execution speed (no more than Time Machine), and would be running in the background just like Time Machine, with no real visual evidence, save for the menu extra, that it's happening.

The solution to running Time Machine is not to run it "when you're using your Mac"...it's simply to understand what's going on, and why.

In addition, for the vast majority of people, myself included, these follow-up runs are Turbo runs...and take a minute or two.

@Dave Really confused by your comment here. I’m not talking about when to run Time Machine; we generally don’t have much control over that. Since SuperDuper runs well in the background, I think it makes sense to run it when I’m at my Mac. That way the backup will be done when I expect, without really any side effects. If it runs overnight and then I log into the Mac and it starts doing a lengthy follow-up, but I want to eject the drives to pack up my laptop, that creates a problem. Often it can Turbo, but there’s no way for me to know ahead of time.

My point is that if it's not a problem that Time Machine is doing its catch-up runs (since they happen in the background anyway), it shouldn't be an issue with SuperDuper either, right?

*Most users* shouldn't be doing what you're suggesting here. I'm not saying *you* shouldn't, given your workflow.

I'm saying, as *general* advice, your suggestion is wrong. Users should not schedule it to run when they're at the Mac. They should generally schedule when they're not...and a quick follow-up when they wake the Mac isn't going to have a significant impact, and will likely be something they won't even notice.

macOS has data protection classes now? Since when? And how do I turn them off, so they're not checked at all?

I dislike the relentless march of a general-purpose OS towards the iOS model where, yes, controlling access based on a "locked" device state makes sense and is defensible.

You can't turn them off, Sebby. And they've been around for a while.

@Dave I think it’s different with Time Machine because (1) it’s making backups many times per day, so usually any protected files that were modified will already have been copied before my Mac locks. Time Machine has worked this way for a long time, and SuperDuper just started, yet it’s already been an issue for me way more times with the latter. And (2), interrupting a Time Machine backup will still leave me with many consistent snapshots committed. All that said, I agree that this is probably not a significant issue for most people.

@Michael Tsai - I have noticed, propably over the last year, that when I check my Time Machine backups in the morning I will sometimes have one or more that have the error worded something like 'backup couldnt be completed because some files weren't available' and it says that now its unlocked they will get backed up. So same thing happend with TM. Annoyed the heck out of me as a backup system should back up, and Apple messing up the system again so something as basic as their backup system not being able to, you know, **back up** the systems...

@Liam Yes, that’s the error. Dave would probably know, but I think that’s been happening for around five years now. What’s weird is that some of the files don’t even seem to contain anything that I would care about being extra protected. (And both the source and destination are full disk encrypted, anyway.)

Without examples even the original blog post doesn't make sense. The blog post says that class D (no protection) is not available. But most files can be backed up without problem. So this makes even less sense. And I never get any errors from TimeMachine or Acronis backups.

Is it me, or should the macOS variants be per-user?

"The class key is protected with a key derived from the user passcode or password and the device UID. [..] On devices with macOS, shortly after the last user is logged out, the decrypted class key is discarded" Why wouldn't that happen when _that_ user has logged out?

"Some files may need to be written while the device is locked or the user is logged out. [..] On devices with macOS, the private part of NSFileProtectionCompleteUnlessOpen is accessible as long as any users on the system are logged in or are authenticated." Why would _someone else_ being logged in allow _my_ data to be accessible?

I could be misunderstanding it, but it seems like they retrofitted a single-user concept to a multi-user OS, with… mixed results.

@Liam - yes, this has been around for some time. I think if you look at the referenced documentation, it's basically as old as APFS, so macOS 10.14 or so, and the concept pretty clearly came from iOS/iPadOS (as did APFS itself).

@Beatrix - well, if it doesn't make sense to you, you're more than welcome to reference the Apple documentation I linked to for more details. That's where it says Class D protection is not available on macOS. That doesn't mean "no protection" is not available, since files can have no protection class at all. It means Class D is not available. The shruggie was there for a reason... :-)

@Sören - Yes, this smells distinctly like it came from the phone. But macOS is *typically* used in a single-user configuration, even though it's inherently multi-user capable. And the Apple documentation here may be inexact or incomplete. (Class B is quite strange, and pretty clearly comes from "phone is locked but email is coming in" type situations.)

This is the first I've heard about this issue. Does anyone know how other backup tools like Carbon Copy Cloner and ChronoSync handle this? I have Carbon Copy Cloner make a nightly backup of my system (while the Mac is locked) to a spinning HDD. It doesn't give any errors, but I also don't notice the HDD spinning up during the day while using my Mac. Does that mean files are being silently omitted from the backups?

These are exactly the sort of restrictions I hate. It should ultimately be up to me to decide what on my computer can access what. There should be nothing that is off limits if I choose to remove the limitation. And a perfect example of why I need this is because backup software *needs* to access everything.

@Bri It seems rather self-defeating in that the workaround is to leave the screen unlocked, which is way worse than not having file protection at all.

@Bri / @Michael - well, no. The best "workaround" is to do what SuperDuper (and Time Machine) does: keep track of what can't be copied with the screen locked, and copy it when unlocked. Then you don't have to think about it.

Of course, if you're using something that doesn't handle the situation, yes: you'd have to ensure the screen is unlocked.

Note that even so, there are some files that are SIP protected and cannot be accessed at all (by design). These include things like Data Vaults and the like...and you seem even need a special entitlement to even *see* that it's a data vault (although that could be a bug in the calls, there is a special entitlement, too)!

It's a challenging maintain a balance between security and access. I think, generally, Apple has done a good job here. But it's still stuff that it's good to be aware of.

ATM I'm on macOS 14, but I realise that I don't ordinarily schedule full system backups. Time Machine never gave me any trouble, and when I do my online backups with Arq, they've been for specific folders. So I suspect I just avoided the situation entirely, but good to be aware of this. I do think Apple is still too nannying here. My machines also run with SIP disabled, for what that's worth, as I generally don't want those restrictions on anything that's not a portable machine that I'm actually travelling with.