Recent discussion has raised questions over how much quicker Time Machine making its first full backup to an APFS volume (TMA) might be, and whether it uses any new tricks to achieve greater efficiency. As I hadn’t previously analysed an example, it needed to be done. Here are the results of a modest-sized first full TMA backup from an M1 Mac mini.

Setting up your first full backup

TMA is now the only means of starting a new backup set in Big Sur. If you present it with an empty HFS+ volume, it will convert that to APFS and use that as your TMA backup store.

Before adding a new backup store to Time Machine, think carefully whether you want to limit the space on that disk which will be used for backups. If you decide that you want to keep anything else there, it’s best at the outset to divide the disk into separate containers, one of which will be occupied solely by your TMA backups. In APFS, containers (effectively partitions) are of fixed size, while volumes can grow until they fill the whole container. The best way to reserve storage space for other files on that disk is to keep TMA backups in their own container. This is because TMA will then thin old backups according to the free space available in its container, and won’t contend for space with your other files.

Although you can present Time Machine with an empty container and it will create its own backup volume, you can also make its life a little easier by creating and naming an APFS volume for it. You can opt for APFS (Case-sensitive) unencrypted or encrypted, as you prefer. Backing up your encrypted Data volume to an unencrypted backup store will always elicit a warning notification, but TMA is quite happy to do that if you prefer. TMA backup stores always use the case-sensitive variant of APFS, though.

The first full backup

Although the first backup is performed automatically by Time Machine, it’s actually scheduled and run as a manual backup, that is to say that it occurs at a fixed time, as shown in the countdown provided in the Time Machine pane, and isn’t scheduled by the normal DAS/CTS system. Indeed, automatic backups which would occur while the first backup is in progress are cancelled. So any DAS/CTS scheduling messages that you might see in the log will keep reporting cancellation until the first backup is complete, when the next backup should be scheduled for an hour later.

If you had previous backups on this system, and this isn’t the first time that TMA has been configured to back up, you may see a succession of log messages referring to the old backup, each cancelling out, before TMA apparently searches mounted volumes which could be used as backup destinations, until it finds the new designated backup store. Although these may appear confused and confusing, they probably cater for situations in which multiple backup stores are in use.

If you have previously formatted the APFS volume for your backup store, you may also see that TMA deletes your original volume and replaces it with one with the same name and a number appended, e.g. MiniBackup becomes MiniBackup 1. Following that, TMA will delete any expired snapshots on the volume(s) to be backed up, and start its normal procedures to perform a backup.

Before the backup starts, TMA produces an estimate of the total number and size of items to be copied, and how much is excluded by its rules and any exclusions you may have set in the TM pane. One significant exclusion which has been added in Big Sur is the hidden and locked folder on each volume containing its local version database; this is to work around the bug which plagued TMH in Catalina when trying to back up large and complex version databases.

For my test volume, the first estimate came to 143.52 GB in 1079122 items, with a further 1.8 GB in 7135 items excluded.

During the copying of files to the backup store, the Time Machine pane gives a convenient and fairly accurate account of progress. If you’re concerned that this seems slow, or simply want more detail, the Check Speed button in T2M2 shows rates of transfer and additional information from the log. If a backup does choke on a very large folder, those log entries include the paths of items which TMA is copying, so can identify where the problems lie, allowing you to add the affected folders to the exclusions list.

Copying speeds attained by TMA are broadly similar to those of TMH, and it’s clear from log entries that, in the great majority of cases, the first full backup copies file by file from the source to the backup store.

Backup complete

Once the first full backup is complete, TMA reports the figures for what was backed up, and how. The totals in my example came to 133.11 GB in 1012818 items. That’s about 7% less than the first estimate, and likely to have been only slightly quicker than an identical TMH backup would have been. Log entries don’t report the effective saving in copying sparse files without expanding them, but they do record the size of files which were cloned. In this case, it was small, at only 273.4 MB over 807 files.

Summary

TMA first full backup:

• is performed automatically, but at a fixed time as a manual backup;
• may be preceded by potentially confusing log entries referring to previous backups;
• excludes each volume’s versions database, which is also excluded from future backups (changed from Catalina);
• is largely performed as a file-by-file copy, just as with TMH;
• is performed at similar transfer speeds to TMH;
• includes significant efficiency savings from clone files, but those may be less than 10% of the total copied from a Data volume;
• is likely to take a shorter time than the same backup using TMH, but the difference may be less than 10%.