Exactly six months ago, when we were running macOS 11.2.3, I looked in detail at the performance of Time Machine making backups to macOS network storage using SMB. Since then, Time Machine and SMB have both matured. This article looks at how that may have affected performance.

On this occasion, the backup was performed between the same two M1 Macs and the same SSDs as before, with my M1 Mac mini sharing an external SATA SSD as the backup storage using SMB in Monterey beta 10. The client is an M1 MacBook Pro, making the first backup of the Data volume from its internal SSD using macOS 11.6. Its only exclusion, following the lessons learned last time, is a copy of Xcode, which previously took painfully long to back up. Both Macs again connected using Wi-Fi 802.11ac, which is commonly claimed to achieve a maximum data transfer rate of up to 866 MB/s.

Copying a standard 10 GB test file using the Finder with SMB took 842 seconds, giving an effective transfer rate of 11.9 MB/s for a normal copy across the same path.

The backup started copying files at just before 1900, and completed the whole backup of 405,718 files totalling 91.8 GB a little after 2200, a total elapsed time of 11,558 seconds, giving an overall transfer rate of 7.9 MB/s and 35 items/s. But, as shown here, this varied widely during the backup. Shortly after 2030, there was a period of about 20 minutes during which no data was reported as being transferred at all, followed by a further flat section, and a final period of over 30 minutes with no transfer apparent.

These periods occurred when two very large files and large apps were being copied, and in the first two cases were followed by periods of reported rapid transfer.

The number of items transferred changed even more erratically, and in quite a different pattern. Two long flat sections correspond with periods during which large single items were being copied.

However, these also suggest Time Machine’s progress reports may be inaccurate and misleading at times.

During copying of one large item between 2009 and 2034, total transfer size rose steadily by 15.1 GB, but during later copies of two large items there was no change in the total data copied for periods of 20 and 16 minutes. This suggests that during some transfers the amount transferred may not be added to the total until that copy is complete. If you’re using these log entries to track the speed of backing up, that could be misleading.

As in the previous test, reported transfer rates were generally between 5-10 MB/s, which is less than that achieved from the Finder. Peak rates attaining 50 MB/s only occur at the end of large file transfers, and may therefore be artefacts resulting from delayed recording of those large file transfers.

Given the very wide range of file sizes in this backup, it’s hardly surprising that the rate of transfer measured as items per second also varies widely, from 0-150 items/s.

Overall, performance seen during this Time Machine backup is only slightly less than that achieved during a Finder transfer, and there doesn’t appear to be any particular penalty when transferring smaller files, so long as they aren’t as numerous as those in Xcode and other pathological examples.

CPU load on the two Macs remained extremely low throughout. On the client, it was too small a percentage of load to be noticeable at all, and on the server it remained fairly steady at 6% and was borne entirely on the Efficiency cores, as expected.

How to estimate likely Time Machine backup times

If you’re intending to back up from Time Machine to network storage such as a NAS or another Mac, the above figures can be used to provide an estimate of how long those backups are likely to take. First, connect to a share on the server, and copy to it a single large file, such as the 10 GB test file used here. Measure the total time for that to transfer, and take two-thirds (0.67) of that transfer rate as the likely overall rate to be delivered by Time Machine. Then use that with your expected average hourly backup to calculate how long that is likely to take.

In the example above, the Finder transfer rate was 11.9 MB/s, giving an expected backup rate of 8 MB/s. For an average hourly backup of 2.4 GB, that would require 300 seconds, or 5 minutes. However, a first full backup of 400 GB would take 50,000 seconds, or just under 14 hours.

If expected backup times are too long, the best time to tune performance or change to a faster network connection is before starting to make Time Machine backups. Use the Finder test file copy as an objective measurement, which will in turn allow you to understand the effect on backup times.

Time Machine settings you should consider for improving performance include:

• exclude items containing many small files, such as Xcode;
• back up very large files such as VMs separately;
• use default automatic hourly backups, rather than backing up less frequently;
• back up to APFS, which works at a block rather than file level, and backs up clones and sparse files much more efficiently.

If the Finder copy test demonstrates that AFP brings a large performance advantage, and your system supports it, you may prefer to continue using AFP. However, you should be prepared for support for AFP to be removed in a future version of macOS and/or model of Mac, as it reportedly has been in Big Sur and Apple Silicon Macs.

If you should encounter poor performance when making backups, use T2M2’s Check Speed feature to identify which items are causing most slowing. Beware, though, that the transfer rates it reports may not always accurately reflect transfer rate during the copying of very large files.