Starting in macOS Catalina, CCC offers a Full Volume Clone method in the popup menu underneath the Source selector. This option is available when cloning an APFS volume (including encrypted APFS volumes and APFS volume groups) to a non-encrypted APFS volume. Unlike the other backup methods that use our custom-built file copier, a full volume clone leverages the "Apple Software Restore" utility that is part of macOS.
Advantages to using ASR
ASR is an Apple-proprietary utility, so it has access to APFS filesystem structures that cannot be accessed by third-party utilities (like our own file copier). Rather than copying files individually, ASR works by generating an optimized stream of filesystem data from the source volume that is copied directly to the destination volume. Because the filesystem structure data is copied directly, there is a lower transactional cost to the procedure, and the result is a much faster clone. Additionally, private relationships between files (e.g. cloned files that share blocks) are preserved, so any space savings that occur on the source due to block sharing are preserved at the destination. In short, ASR can clone a whole volume faster and preserve all of the private filesystem metadata.
Copying "snapshot deltas" with ASR
While an initial or one-time whole-volume clone via ASR is faster than a file-level copy, cloning the whole volume every time would be slower for subsequent backups than making incremental updates to the backup volume. In macOS Catalina, Apple made an improvement to ASR that allows it to copy just the differences between two snapshots of the source volume. So for example, suppose that today do a full-volume clone to the destination volume. At the beginning of the task, CCC creates a "checkpoint" snapshot on the source, and then invokes ASR to clone the source to the destination. Now both the source and destination have the exact same content, including a copy of that Checkpoint snapshot. When you make a backup of the source again tomorrow, CCC creates another Checkpoint snapshot on the source volume, and then instructs ASR to copy just the differences between yesterday's snapshot and today's snapshot. As long as the Checkpoint snapshot still exists on both volumes, the destination will be updated to match the exact state of the source, but by copying just the differences. In short, subsequent backups are really fast.
There are a handful of cases where ASR integrates poorly into a robust backup strategy. These cases are listed below, and as applicable, the numbers in parentheses correlate to feedback that we've offered to Apple.
Vague error messages (FB7338920)
ASR is an Apple-proprietary utility, so our insight into its internal workings is extremely limited. When ASR encounters errors, it prints an undocumented error message, and we're left to make guesses about what they mean based on context, trial and error. For as many cases as possible, when ASR produces errors, CCC will present helpful advice for dealing with the problem. In many cases, though, CCC will suggest that you use one of the traditional file copying methods instead.
Logistically incompatible with encrypted destinations (FB7332101)
If the destination volume is empty, or if it lacks a common snapshot with the source, ASR will erase the destination as APFS (not encrypted), regardless of whether the source volume is encrypted. You're welcome to enable encryption on the destination, but if you do so, ASR will subsequently fail to identify the last common snapshot as common between the source and destination, and will erase the destination volume and perform a full volume clone. Because this negates your efforts to maintain an encrypted backup, we do not currently support the Full Volume Clone method with an encrypted destination.
ASR cannot handle any amount of filesystem corruption or media errors (FB7338920, FB7324207)
Physical media failure and bugs in filesystem code can both lead to filesystem corruption. Filesystem corruption is inevitable, even on APFS. If you write a backup application, you're going to run into filesystem corruption, so you have to deal with it. We field filesystem corruption-related support requests every day. It's a part of life. With a file-level copy, we have a lot of context during the backup task. Typically we can see exactly which files are affected, and in many cases users are able to "excise" the corruption by deleting the affected files. This allows us to avoid the "nuke and pave" recommendation that you hear so frequently from "senior advisors" at other companies. It also allows us to skip past the corrupted files and copy as many of the other still-readable files as possible. That's obviously helpful if you're trying to recover files from a failing disk.
When ASR is copying the raw data of filesystem structures, however, it won't necessarily know which files are affected if some block of media is physically unreadable or if some filesystem structure can't be processed into a stream of data. More importantly though, ASR chooses to not work around the error. If any filesystem structure is unreadable, ASR aborts the procedure, and worse, it leaves the destination device in an unacceptable condition (more on that next). In these cases you're left with no backup at all and no indication of which content on the source is affected by the corruption. So if there is any possibility that filesystem corruption exists on your source volume, and especially if you're trying to recover data from a potentially-failing device, you're better served by CCC's traditional file copying method.
There are many reasons that people stop a backup task. Perhaps it's just running at an inconvenient time, or maybe you want to change how it's connected to your Mac because you realized that it's connected to an ancient USB hub. If you stop a backup task that's using CCC's file copying method, the task exits gracefully, and when you run the task again, CCC gracefully picks up copying where it left off. ASR is not as graceful. When you stop an ASR cloning task, the destination APFS container is corrupted, and the destination device is completely unresponsive.
Solution: Fortunately this is transient corruption, so you can simply detach the destination device physically from your Mac (or restart), then reattach it to regain its functionality. Once you've done that, you must add a new volume to the destination APFS container in Disk Utility. Normally CCC would do that sort of cleanup for you, but given the completely unresponsive state of the destination after the aborted ASR clone, CCC doesn't have an opportunity to do that for you when you stop the task.
ASR doesn't offer a method to validate the destination data
When copying the differences between Checkpoint snapshots, ASR doesn't validate the data on the destination (e.g. older data) against the source. If media failure or filesystem corruption occurs on the destination that doesn't affect the content that's getting updated, it will go unnoticed. If you never validate your backups, you may not discover the failure until you try to recover data from the backup.
This is an opportunity to demonstrate, however, that ASR is just a part of a larger backup strategy. Fast performance is definitely a factor that you'd want to consider while crafting your backup strategy, but data integrity has to be there too. For that aspect of your backup strategy, CCC offers a Find and replace corrupted files feature. That feature requires that you choose the "Copy all files" or "Copy some files" cloning method, but you can configure that in a separate task that runs on a monthly or quarterly basis if you would like to use the Full Volume Clone primarily.
If you delete a Checkpoint snapshot from the source or destination, ASR has to clone the whole volume again
ASR's ability to perform fast "snapshot delta" updates to the destination relies on the retention of those Checkpoint snapshots on both the source and destination. If you delete a Checkpoint snapshot from either the source or the destination, ASR will be forced to recopy the entire volume during the next backup. CCC will warn you about this result when you delete a Checkpoint snapshot (and you can identify a Checkpoint snapshot by hovering your mouse over the snapshot type icon on the right side of the Snapshots table), but there's nothing to prevent other applications from deleting those snapshots. From what we've seen so far, Time Machine is very respectful about not deleting snapshots created by CCC. The macOS Installer, however, will delete snapshots on the volume that you're installing onto. There's nothing you can do to prevent this from occurring, rather it's just a piece of context to keep in mind about how the Full Volume Clone method works.