Here be Monsters
This is a sort of technical post. If you’re not interested in the details of what’s happening during a backup, what files can and can’t be copied, when, and why they’re harder to do properly than you might think, feel free to skip.
Class is in Session
Recent versions of xOS (that is, macOS, iOS, iPadOS, etc) have Data Protection Classes from A to D that get assigned to files and folders.
Some files have Class A protection: where an application has specifically marked files that it thinks should not be accessible to anyone without authorization.
Class B protection means a file cannot be accessed by anything unless it’s open. That is, even if a device is locked, the file can be created and written, but once closed, Class B is treated like Class C.
Note: Since Class B files are created when Class A keys are not available, they’re encrypted on a per-file basis, in addition to normal FileVault encryption.1
Class C are files that are inaccessible after reboot until you log in. Once you’ve logged in, they remain available, even if the Mac is locked.
Finally, there’s Class D: no protection. Curiously, this is not allowed under macOS. ¯\_(ツ)_/¯
The thing is, though, is that these files and folders are inaccessible unless the user is logged in, and the screen is unlocked. A few seconds after the screen locks (or you log out), the keys are purged, and they cannot be read.
And there’s no “easy” way to find out what files are what.2
That Seems…Good?
From a privacy/security standpoint, this is obviously good. Someone who gets into your computer cannot access those files unless the drive has been unlocked. On a phone, that means a locked phone has data that’s inaccessible, even via the USB port.
From a backup perspective, though, this is…troublesome.
Troublesome because people tend to schedule copies for when they’re not at their Mac. And if they’re not at the Mac, the screen is almost always locked.
That means the files any application considers to be worth protection cannot be accessed when a backup usually happens.
By anything. Even a backup program with “root” access.3
I Take it Back. That Seems…Bad?
Certainly if important files are marked as Class A, and those files are never backed up, that would be quite bad. And even Class C files are unavailable if you haven’t logged in yet…a broader class of files that could get missed until the next time you back up with the screen unlocked.
Which, given the way people schedule backups, may never happen.
Time for a Follow-Up
Fortunately, SuperDuper handles this with relative ease.
You may have noticed that if you had an overnight backup, when you unlock your screen, a copy starts to run. It’s typically quite brief, thanks to ⚡️Turbo Smart Update, but it might surprise you anyway.
If you look at SuperDuper when this is happening, you’ll see a little pill in the job that says it’s a “Follow-Up” (or, hopefully, ⚡️Turbo Follow-Up).
So what happened?
During your overnight copy, SuperDuper kept track of the files that it couldn’t access due to their protection class. And now that it can access them, it’s making sure they get backed up.
A Million Little Pieces
These are the kinds of details that are involved in putting together a backup program you can count on. There are a million little details, things that’ll catch you out if you’re not extremely careful.
It’s not so much that a file might be written with the wrong bytes, or that you’d have bit-rot…that’s incredibly rare, and the hardware is designed to deal with it to a great extent. But missing files?
That’s not something you should have to worry about. But I do…which is why SuperDuper handles it, without any fuss. You don’t even have to think about it.
And now you never have to think about it again.
-
I’m guessing (when things aren’t open source, it’s very hard to investigate this kind of stuff), but I think that when you have too many of these types of “individually encrypted” files on an APFS drive, the replicator barfs with an obscure
E2BIGerror, even if the screen is unlocked. And there’s no real way to fix it. ↩︎ -
For the curious, the protection class is available via
fcntl(fd, F_GETPROTECTIONCLASS), set viafcntl(fd, F_SETPROTECTIONCLASS, class)andopen_dprotected_np(...); when set on folders, everything in the folder inherits the class (similar to an inherited ACL). ↩︎ -
If you’ve ever tried to make a bootable copy and received a
Resource Busyerror, I think this is because the replicator has run into APFS structures that are holding Class A protected files when the screen is locked. Since it can’t replicate those blocks (they’re locked and the key has been thrown away), and the copy would be structurally invalid without them, it fails the copy. With a very obscure error.
To try to deal with this, if you schedule an Erase, then copy bootable backup, and the screen is locked when the time comes for it to start, SuperDuper postpones the replication until you log in. And when a replication is running, we use an assertion to keep the Mac awake, with the screen on. ↩︎