In the last article in this series, I looked at how Time Machine (TM) copes with major change, giving further insight into how it now works in Catalina. As with previous articles in this series, I focussed there on TM backing up to local storage, such as an external disk or RAID system. Many TM users prefer to back up to networked storage (NAS), which is the subject of this article.
TM was designed to make backups to HFS+ formatted disks. Just a few months after its introduction in Mac OS X 10.5, Apple shipped its first Time Capsule, a combination of AirPort Base Station and networked hard disk. To support that and other NAS, TM had also been designed to be able to back up over a network using AFP, now replaced by SMB. As TM requires backup storage to support features peculiar to HFS+ such as directory hard links, this requires a networked backup to be stored in a sparsebundle, which effectively provides a virtual HFS+ file system.
The concept is alluring: you open your MacBook Pro, it automatically joins your Wi-Fi network and connects to your NAS. TM then makes an automatic backup without you even being aware of it. No wires, no mess, no fuss.
Look inside, though, and the process is considerably more complex and prone to problems and failure than backing up to local storage. TM talks through SMB (or AFP) to the networked storage, which in turn hosts the sparsebundle to provide virtual HFS+. With all those protocols and standards involved, what could possibly go wrong? As some have discovered, almost everything and anything.
The first full backup is almost inevitably slow and painful, and subsequent structural changes in macOS, as have happened in Catalina, can result in what is effectively another full backup, which some users find never completes. The maximum size of the sparsebundle is set when it’s created, which can conflict with server quotas set for shares, leading to failure to back up because there is inadequate space despite NAS storage being almost empty.
Recent versions of macOS now default to using SMB. In the case of Catalina, that means SMB3, although Apple claims that older versions of SMB are still supported in the event that an SMB3 connection can’t be negotiated. But if you still mount network shares using old shortcuts dependent on AFP, that is how TM may try to connect, irrespective of what you have specified for TM. The most robust way to tackle this seems to be disable AFP on all NAS which support SMB. It may also help if you’re not connected to the NAS in the Finder, before you start setting that up as your TM backup destination.
Apple provides old information about Time Machine over SMB which may still be useful when configuring a NAS, but doesn’t appear to provide anything more up to date. This article provides up to date information about the types of backup storage which you can use, and more general information about backing with Time Machine is here.
TM sets the size of the sparsebundle when it’s created, allowing it to grow in size as required up to that limit. However, that maximum can only be increased, not decreased, it appears. Setting a subsequent server quota on the share or on that user is therefore likely to result in an error, in which TM complains there is not enough space on the backup volume, when there is still plenty. The only solution then is to remove all quotas, or to start a new backup.
Although sparsebundles seem to work well much of the time, they also appear peculiarly liable to corruption. Some users have come to expect them to fail after about two years, and maintain a duplicate copy of their backups ready for that moment. As sparsebundles are effectively HFS+ file systems, they can be maintained and repaired using tools designed for that file system, including Disk Utility, and Alsoft’s famous DiskWarrior.
Some users recommend preventive maintenance at quite frequent intervals, perhaps checking and repairing the sparsebundle every month or so using DiskWarrior. Although that should certainly optimise directory structures in the sparsebundle and keep it working efficiently, it’s not clear why (or even if) it should have a propensity for developing errors.
Problems and solutions
One of the traditional recommendations is to make a first full backup (and all subsequent large backups) using the fastest connection possible to the NAS, such as over wired Ethernet rather than Wi-Fi. This not only reduces the time required, but anecdotally appears to increase the chance of success. This is also probably true of the first backup made after upgrading to Catalina: because of the structural changes made to create separate System and Data volumes, that can be a large and complex backup, and prone to failure.
One strategy for upgrading to Catalina which is worth considering is turning TM off before upgrading, and archiving your existing backups. Then, when the upgrade is complete, start a fresh backup set. However, as that will definitely require all volumes to be backed up in full, that is best performed using the fastest network connection too.
With so many different protocols and systems in play during a backup, diagnosing problems, such as a stuck backup which never completes, can be very hard indeed. Is it
backupd, something else on your Mac, SMB/AFP, networking, the sparsebundle, or the NAS itself? The diagram above suggests some diagnostic tools which can be of help, although some such as network packet sniffing are not simple by any means.
Apple recommends that all TM backups should be encrypted, which can be straightforward if it’s a feature already supported by the NAS. Adding encryption/decryption steps to an already tenuous system isn’t going to make life any easier. With several users sharing a single NAS, it may though be essential.
Making your own NAS
Since Apple started dismantling its former OS X Server product, it has incorporated a TM server in the standard release of macOS, controlled and configured in the Sharing pane. Select the File Sharing item at the left, then add the folder in which backups are to be stored to the list of Shared Folders. Select that folder and bring up the contextual menu, at the bottom of which you’ll see the Advanced Options command.
That opens a dropdown sheet where you configure that backup store.
Just as on a dedicated NAS, backups on that storage are in sparsebundle format, and use SMB/AFP, so it’s quite possible to host them on an SSD formatted using APFS, something not normally attempted with local backup storage.
I’m very grateful to the numerous readers and other correspondents who have provided much of the information which I have summarised above. This series is dedicated to James Pond (1943-2013), who really did know everything about Time Machine.