This summer it will be ten years since Apple discontinued its last Time Capsule, the end of the line of products for which it introduced Time Machine. Although most of us using Time Machine now back up to local storage, Apple continues to support it making backups over a network, either to another Mac or to network storage such as a NAS. This article looks at some checks and balances you'll find Time Machine making when it backs up over a network, in Ventura 13.2. In this case I'm using an excellent Asustor AS6702T.
There are two major differences in backing up over a network: rather than Time Machine writing its backups through a local file system, now APFS (although legacy backups to HFS+ are still supported), a network file system is used instead. With AFP long deprecated, unless you still have to support older macOS, SMB is much preferred, and used here. This article won't explore those intricacies, though, but concentrate on the other difference, that backups are stored in a sparse bundle. This provides a virtual file system with structured directories containing thousands of band files, suitable for storage on a wide range of different native file systems.
Creating the sparse bundle
Making the first backup to network storage has other requirements before it can create the sparse bundle. Among them is storing the password for access to the storage together with its URL in the system keychain, to ensure Time Machine (TM) can connect to make future backups.
Once those are complete, TM picks a band size to be used by the sparse bundle. This is typically 256 MB for storage of around 4 TB, giving the maximum number of band files as 16384. This should be recorded in the log, for instance as
Using a band size of 256 MB (max bands set to 16384, image size 3.74 TB)
The file system within that sparse bundle is set to be Case-sensitive APFS, as it would be on local storage.
Checking the sparse bundle
Once the sparse bundle has been created, TM checks it for "runtime corruption", as it does before starting each backup to it. These checks can take significant time to complete: an empty 4 TB sparse bundle might require more than 3 seconds, although that should fall to around 1 second on subsequent backups.
These checks are performed primarily by com.apple.DiskImages2 and its service /usr/libexec/diskimagesiod, which give a blow-by-blow account in the log. They work through SMB (as smbfs) to attach and mount the sparse image, and perform a check using fsck, which should be reported as returning a status of 0, indicating a clean file system. These appear similar to those normally reported when attaching and mounting sparse bundles, with the added complication of SMB as the intermediary network file system. When checking these in the log, it's important to note that a sparse bundle normally contains more than just the single APFS volume, and the volume you want is usually the last to be attached and mounted.
Key log entries seen marking this for a sparse bundle named MacStudio.sparsebundle might read:
Checking for runtime corruption on '/Volumes/.timemachine/ASUSTOR (Time Machine: SMB)._smb._tcp.local./5A7D3A8D-E473-4E14-AD30-CE2FB67C4BA2/Public/MacStudio.sparsebundle'
Successfully attached using DiskImages2 as 'disk4' from URL '/Volumes/.timemachine/ASUSTOR (Time Machine: SMB)._smb._tcp.local./5A7D3A8D-E473-4E14-AD30-CE2FB67C4BA2/Public/MacStudio.sparsebundle'
Runtime corruption check passed for '/Volumes/.timemachine/ASUSTOR (Time Machine: SMB)._smb._tcp.local./5A7D3A8D-E473-4E14-AD30-CE2FB67C4BA2/Public/MacStudio.sparsebundle'
If your Mac reports a problem attaching or mounting the backup sparse bundle, then it's worth locating the time of the first of those log entries, perhaps by viewing only Time Machine entries in that log browser in Mints. Round that time down to the nearest second, then browse the whole log for a period of 10 or more seconds from that time using Ulbow. Entries should then reveal full details of exactly what failed, why, and whether any attempt was made to repair it using fsck.
Checking performance
The next step is relatively new, and consists of two checks of write performance on the backup storage, the first for a single 50 MB file, then for a rapid succession of 500 4 KB files. The latter test appears prone to failure on network storage, though, with results like
Checking destination IO performance at "/Volumes/Backups of MacStudio"
Wrote 1 50 MB file at 315.88 MB/s to "/Volumes/Backups of MacStudio" in 0.158 seconds
Failed destination write test with error Error Domain=NSPOSIXErrorDomain Code=60 "Operation timed out". Wrote 246 KB across 60 files.
No significance seems to be attached to such failures, though. Again, these are readily read using Mints.
Completing the backup
The final notable log entry for a first backup records setting of the quota:
Set quota for '/Volumes/Backups of MacStudio' to none
On completion of that first backup, the log records
Closing device lock assertion taken at 2023-01-31-043531 with reason: Backup Completed.
I hope these log landmarks prove useful for anyone trying to diagnose problems with backing up to network storage. While T2M2 remains a useful tool for checking on TM backups over a network, because of their added complexity you'll find the Time Machine log browser in Mints of more use, particularly when displaying only Time Machine entries, and turning off the other three, DAS, CTS and other.
