APFS encryption, volume snapshots

System:
MBA M1 16 GB/1TB, System/Data volumed with APFS encryption/filevault activated, Big Sur.
Parallels 17.1.1, Parallels' own encryption/password not activated, Windows 11 Pro ARM Release version, Bitlocker not enabled, vTPM enabled. PVM currently residing on DATA volume.
CCC 6.

terminology: parallels snapshots = snapshots taken by parallels software. APFS snapshots = snapshots take by MacOS of a volume. backup = backup to an external drive (or to a different location of the same volume/drive).

Hello,
my goal is to optimize Widows performance and to ensure that APFS snapshots always contain functional versions of the PVM including Parallels snapshots.

It is possible to trigger APFS snapshots via the command line, but their retention length policy is managed by MacOS to my knowledge.

Time Machine itself will always create snapshots of a complete volume -- to my knowledge, exlusion of individual pvm files is ignored pertaining to the snapshot (and only applied pertaining to the extermal backup).

I believe it might be possible to separate snapshots by creating separate volumes and using CCC which includes its own snapshot creation and retention module.

TO my knowledge, CCC triggers a snapshot of the complte source APFS volume whenever any kind of backup task is created for it - and can optionally retain that snapshot. The retention policy is per-volume, to my knowledge (?). It is certainly not per backup task.

Since automatic backups will trigger a snapshot, the timing will typically coincide with a running PVM, creating an inconsistent PVM snapshot.

Parallels features an option to "optimize for time machine" -- but this will limit the amount of automatic snapshots (for no good reason?), and arguably (?) only affects the consistency of external backups, not internal snapshots if I am not mistaken, requiring permanent connect to a backup drive (?). I believe this because the exclusion of files is not possible with snapshots.

Creating a separate volume just for the PVM, within the same apfs container that contains DATA and the SYSTEM volumes, might solve the problem. One could then define scheduled CCC backups with a reasonable retention policy for the DATA/SYSTEM volumes to trigger snapshots (the actual backup task triggered is of secondary relevance here and could just be a means to an end (=snapshot), and a separate manual backup profile that will perform a backup and thus trigger a snapshot on the PVM-dedicated volume.

This manual snapshot would ideally be triggered whenever the VM is paused or shut down. It is in this context that I am also wondering if the mere pausing of the VM has equally high chances of resulting in a consistent, usable PVM file as shutting down Windows has. What happens to RAM when a VM is paused?

APFS encryption of PVM volume:
Upon creation of a PVM-dedicated volume I am wondering if I should or should not enable APFS encryption if I am not worried about physical theft of device and also do not have enabled the finger print scanner / password except for reboots etc. I am wondering if the VM might run significantly faster on a non encrypted apfs volume and if this will have any disadvantages, at any point. Will not encrypting the volume affect the interaction of the data volume with the pvm-dedicated volume, for example when it comes to the required vTPM keychain. Will not encrypting affect negatively backups of the full complete drive, etc.
(As a side note I remember that not encrypting my iPhone backup resulted in loss of some data (some passwords and health data) upon migration to a new iPhone). As far as I can tell, APFS encryption and logging out the user seems to be the best choice, rather than bitlocker and paralell's pvm encryption, if one does choose to encrypt?

 

Update:

I created a new encrypted APFS volume named "Parallels" in the same container as "DATA" on my internal SSD.
I shut down my PVM and moved it there, then double clicked it - it worked from the new location with now vTPM or other worries. PVM settings seemed to be stored within the PVM file.
I created a new CCC profile that would run manually and trigger a bogus backup within the APFS volume named "Parallels", and configured the snapshots to keep around 400 GB of my 1TB untouched (of which 250- max 350 GB are used). Running the CCC profile whilst the VM is shut down indeed seems to trigger a snapshot of that AFPS volume only, and should include previous, FUNCTIONAL states of the PVM -- and indeed it seems to grow only incrementally by smaller changes that have happened to the PVM file: three boot ups and shutdows resulted in the snapshot growing by 1,3 GB "only".
I do not know if a shapshot taken when the PVM is running almost inevitably results in a completely useless PVM file -- or if typically the last PVM (!) snapshot state (i.e., snapshot made by parallels) will still boot.
As a next step I am going to enable APFS snapshots for the DATA drive again in CCC for DATA/SYSTEM no longer contains the VM -- I wonder what that entails, as now two speapare CCC snapshot sets (for the DATA/SYTEM and PARALLELS volumes) will be competing for the same space of the container, esp. if I configure 400 GB to be left as free space. Perhaps I should have created containers instead?

I am also thinking of formatting a 1TB SanDisk Flash Drive / SDXC card as a permanently attached backup drive in case of MacBook hardware failure, and subdividing the drive into two containers/volumes (which?), and running backups there (one for parallels pvm volume, one for data) - but using either CCC or TM, or both, might come with its disadvantages each - even if you mitiage some with https://www.cultofmac.com/526517/how-to-stop-time-machine-backing-up-every-freaking-hour/ .

Googling for _carbon copy cloner delta_ will not reveal any results, whereas Time Machine seems to take advantage of mechanism to reduce data being transfered (see "delta"):
https://eclecticlight.co/2021/03/17/time-machine-to-apfs-backing-up/

How this will affect backups to external flash drives when backing up a volume with a PVM I do not know - but I could check as the time it will take will clearly show what's happening: If a changed PVM (after a boot and shutdown) will take super short with TM backup to SDXC, but very long with CCC, for example, it would be obvious what's happening.

 

I have new information directly from Bombich Software, the makers of Carbon Copy Cloner.
As a side note, I would like to mention here that the support and quality of the software is really remarkable!
So they said:
- There are no extra handling rules for multiple snapshot sets sharing the same container. They say "there are many ways to approach this,
e.g. having different snapshot retention policies for each volume, and/or you could consider using volume reserves or quotas (during volume creation)",
and they comment that they would by tendency avoid the latter because one loses flexibilty (see later). They say one could als "consider creating separate
partitions (and thus different containers)." They say they recommend managing "all of this via the retention policies and task scheduling because that
will offer the most flexibility [because] with partitioning and reserves, those choices are harder to change once you've populated your backups."

I asked them if this "can be handled by setting upper space limits for each volume instead of using a new container, and if snapshots will honor the upper
space limit set for a VOLUME pertaining to the trigger for snapshot thinning, or are they looking at the total CONTAINER free space. They answered
that this WILL work: They said that "when you set a quota on a VOLUME within the container, the snapshots on that volume will be limited based on [THIS] quota."
Again they comment that "this is less flexible than changing the retention policy settings because you can't adjust the quota [of a volume] once it's set.
If you want to change or remove the quota, you have to delete the volume, which deletes all of the snapshots on that volume (without affecting other
volumes in the container)." (Note though that this is just about a simple container with the PVM, so if one did want to change the quotas, it would
not be very difficult, one would just move the pvm elsewhere, delete the volume and create a new one and move the pvm back -- if this will affect backups based on the old volume, I don't know, but one will do that just once or twice anyway, if at all. Note that the snapshots of the volume that one has limited are still going to be competing with the snapshots of the other volume in not-really predictable ways, I guess only a separate container will fix this - or a retention policy where the size limitations are never going to be the limiting factor in the first place. -- In that sense, it is indeed good to just create non-restricted volumes, play with retention policies, and just observe for some time what happens to free space and snapshots in the formidable CCC snapshot viewer (CCC can show you the snapshots' sizes, and also maneuver through them showing you the differences on a file by file /folder by folder basis)). Note also that in monterey, disk utility can show snapshots, but big sur can't (ccc can do it in either case) -- of relevance if you are still being careful about monterey because of the memory leaks issues.

As to the question whether CCC, when doing a backup of a pvm file, will do some form of block level / delta copying, or copy the full 200 GB each time even if just
a byte has changed, Bombich software explains that that "actually depends on what kind of devices the source and destination are. If the source and destination are both APFS-formatted solid state devices, then CCC will do a block-level analysis of any files that are larger than 1GB. In those cases CCC will use the "clonefile()" function to create a copy of the existing file on the destination, then compare each block of the source and destination and copy just the differences. That results in a much smaller footprint for any snapshots created on the destination." I will add here that this should, as far as I can tell, also result in less data copied and thus less wear, and possibly faster performance depending on circumstances. Bombich Software adds that "the performance of this procedure is completely unworkable for non-solid state media.", and that it could even cause slow down on some solid state media in some cases and that there is an option to disable it. (I haven't found that option, I guess it's not readily accessible in the interface)

 

So, I have been using this setup and it works nicely. I run the "bogus" backup on the dedicated parallels volume on my internal SSD whilst parallels pvm is not running. I have set CCC to retain one snapshot per day for 8 days and one per hour for 24 hours, and leave 350 GB of free space on my 1 TB SSD. Snapshot creation takes just one second. This provides me with an addional level of safety in case of any currution / issue with Windows:
Layer 1: Regular PVM copys on external 2 GB T5 SSD
Layer 2: PVM APFS snapshot on internal SSD as described above
Layer 3: Parallels' own automatic snapshot within the PVM file.
Layer 4: Macrium Reflect diff/inc system image (not bootable) to external permanently attached 1 TB flash
Layer 5: Macrium Reflect 15-Minutes Files/Folder diff/incr backup (user files) to external permanently attached 1TB Flash
Layer 6: AllSync 5 Minute File History backup to external permanently attached 1 TB Flash

This only covers the VM. Backup of MacOS is another setup, using CCC, iCloud and a different SSD. I only user Firefox on Mac, other than that I use windows. Thus the level of safetly is not so important there.

 

To go back to a previous PVM, you go to CCC, Volumes, select volume where PVM is stored, go to snapshots, rightclick snapshot you need, click show in finder, then copy this old version PVM to your desired location.

 

If anybody knows whether a PVM file of a PAUSED VM is as suitable for a consistent backup (copying) / APFS macos snapshot (via macos snapshot) as a VM where windows has shut down, please let me know. thank you. I.e. if one copies the PVM file whilst the VM is PAUSED: what will happen when that copy of a paused VM is launched?