Steven Haver wrote:Hello!
Greetings!
That's a lot of questions, but I'll see what I can do...
As far as I can tell, there's not an easy way to create/restore static images on an APFS volume.
There are, but I wouldn't call them easy. Apple's
asr command-line utility was extensively modified to make and transfer copies of APFS volumes and containers. And I believe tools like Carbon Copy Cloner has some of this functionality baked in. I sometime use these during testing (to quickly create a freshly installed operating system, for example), but these days I'm not a fan of trying to preserve copies of your system volume for later restoration (I'll explain later).
I see that APFS supports snapshots but they seem limited to me: 1) the snapshot is stored on the local disk, so in the event of failure that snapshot doesn't exist anywhere else. 2) Is there a risk that some malware finds a way to escalate privileges and then mark itself as part of a previous snapshot? Perhaps that is a baseless concern. 3) The OS seems to have all the control over snapshots, so even if I make what I consider to be the perfect snapshot, OS X may at some point in the future decide that snapshot is old and delete it (keeping, perhaps, newer ones that it made itself but are not useful to me).
1) Snapshots are not backups
2) This is impossible. Ignoring how the malware would get these privileges in the first place, snapshots are read only. There is nothing in APFS that allows code to modify a snapshot once it's been taken, so no ... malware can't use a snapshot to "fly under the radar" as it were.
3) Again, snapshots are not backups.
Snapshots are used for versioning, and are a tool for making clean backups. But they are not backups nor are they substitutes for backups.
Backups (including QRecall) use snapshots to "freeze" the state of the volume so that it can leisurely backup all of the data
as it existed at a particular instant in time. macOS also uses multiple snapshots on laptops, when mobile, to persevere the state of the volume at different times so, when the laptop is later reunited with it's backup volume, all of those snapshots can be transferred to the backup. But then all of the snapshots are discarded. So think of snapshots as a temporary vessel for a backup, but it isn't a backup and they aren't persistent.
One of my concerns is for my software licenses. I do audio work, and I own quite a few audio plugins. Many of them are registered by a key and often that key is single use.
QRecall (like all competent backup programs) will persevere, and later restore, all of the files on your system volume. If your software license keys are based on the data and metadata of those files you should be fine. However, some licensing enforcement schemes use other information (like taking a fingerprint of your hard drive or saving the inode of a file) and that's beyond the scope of backup software. I remember once adding memory to my computer, only to find that Photoshop wouldn't launch anymore because it was convinced I had copied it to another computer. QRecall can't protect against that.
My other concern is about backing up while the OS is running. Are there any risks for doing live captures of Catalina?
Returning to snapshots, Catalina, system volumes, and QRecall.
Catalina splits your startup volume into two different volumes. A read-only
System volume containing the entire core operating system, and a read-write
Data volume that contains all of your data and anything that changes (preferences, cache, history, ...). This fact is hidden from the casual user (and most software) with some slight-of-hand that makes these two volume appear to be a single volume. The idea is that malware can't modify or corrupt any system file because the volume it's on can't be modified.
Because the System volume is read-only and can only be created by Apple's macOS Installer, QRecall no longer backs up the System volume. It only captures the read-write Data volume. Following some catastrophe, you can restore your entire system by restoring all of data from your archive to a (newly created APFS) volume, then run the macOS Installer to turn that volume into a bootable System+Data pair.
Having a minimal system and a copy of QRecall on a thumb drive makes this simple: Boot from external USB thumb drive, use Disk Utility to create/format an empty APFS volume, open QRecall archive and restore entire startup volume, run macOS Installer, and you're back in business. (Note if your archive is stored on a bootable hard drive you can simply install an emergency copy of QRecall and the OS on the same volume.)
The advantages here are: (a) minimal archive size because QRecall isn't backing up system software it can't restore on it's own anyway and (b) a clean operating system is always reinstalled from a safe, reliable source.
Would there be any benefit to making a bootable clone (with CCC or Super Duper or something?I've never used either) and running the initial QRecall capture from the clone so that the internal start up volume is not active at the time?
No advantage because of snapshots. Again, every QRecall capture starts by making a temporary snapshot of your volume and then it captures that snapshot.
And in closing, I'm not a fan of partitions ... they're soooo 1990's. All modern filesystem (ZFS, APFS, ...) treat a "volume" as a fluid, flexible, entity that can dynamically resize itself and span multiple physical devices. Making partitions just makes your life harder. That's my opinion, at least.