I use QRecall to capture my VMware virtual machine file. It was my understanding (from knowledge I picked up years ago), that virtual machine files should not be backed up while in use. The problem, as I understood it (which means I may be wrong) was that the backups could be corrupted in some way, so that if you ever had to restore the VM file from a backup, you might find out that the restored VM no longer worked. I think the general idea was that it takes a long time to backup a VM file, so the state of the file is constantly changing while you're backing it up. Thus, I've always had an archive setting in my archive file to not capture the folder containing my virtual machine files, so I don't have to worry about a capture action running and capturing up a VM file while it's in use. Then I have a separate archive file just for capturing the VM files. I only capture the VM files after I've exited all VMs, and then I manually run my action that captures the VM folder to the second archive.

Recently, I've upgraded all my volumes to APFS volumes, and I noticed that the release notes for one of the recent updates mentioned that QRecall now takes a snapshot of volumes before capturing them. I don't yet fully understand what APFS snapshots are and how they work, but I'm wondering if this means I can simplify the process I mentioned in the first paragraph. Is it now safe to capture a VM while it's in use? Or was that never really a problem to start with? Can I dispense with my second archive and second action, and just capture the VM folder normally to the primary archive, without having to worry about whether the VM is running or not? What's the "best practice" here?

-- Bruce

Snapshots help, but don't totally solve, this problem.

An APFS snapshot is just that: an instantaneous copy of the entire volume, frozen at a point in time. (Naturally, the filesystem doesn't actually copy the entire volume—it's all just metadata slight-of-hand—but the effect is identical.) Any further modifications to the volume (writing new data, creating new files, deleting files, and so on) happen on the "live" version of the volume and does not alter the snapshot.

This helps make the backup process much more stable and it doesn't have to worry about race conditions like files being added or deleted to a folder after QRecall has read the directory to find out what files it contains.

It does not, however, solve the fundamental problem of data that hasn't been written yet. The issue with virtual machine files (and databases, and large media files, and so on) is that they are still being written to while the capture is in progress. The backup copy is then a half-written file that is unlikely to be usable. Snapshots don't really change this equation, it just changes the point in time that the captured data is out of sync with the file as it will be written.

Snapshots can, however, make it easier to live within these constraints. The best solution QRecall can offer is a slightly modified version of the solution you already have.

You're already doing the right thing—closing all of your VMs before starting the capture. QRecall can automate this if you schedule the VM capture action to start as soon as your VM software application quits. This way, you don't have to remember to do anything; whenever you quit your VM software a capture will start immediately.

The beauty of APFS snapshots means you don't have to wait for the capture to complete to get back to work. As soon as the capture starts, it will have made a snapshot of all of your VM files (in their closed, pristine, state). You are now free to launch your VM software and start working again; new changes to the VM won't be part of snapshot or the capture that's in progress, no matter how long it takes.

Thanks for the clarification. Now I've got a better understanding of what's going on.

However, scheduling a capture action to start as soon as the VM app quits doesn't quite work for me. The problem is that I don't usually quit it until I'm done for the day (this is a work computer) and ready to head home. And it can take 30 minutes or longer for the capture to complete. So I'm thinking what I should do is schedule the capture to occur very early in the morning, at a time before I normally arrive at work. (The computer is shut down when I'm not there.) Then when I arrive at work and boot up the computer, the action would run immediately. I wait a few seconds to give the capture action time to generate the snapshot, then I can start the VM. Does that sound reasonable?

That would, absolutely, work too.