Following the completion of my on-site backups, using a combination of Carbon Copy Cloner, ChronoSync and Time Machine to SSDs in my ThunderBay 4 enclosure, I’ve now got the following cover:

1. fine resolution versions when saved, using the macOS version system (minutes to hours);
2. an hourly Time Machine backup of just my main working folder (hours to months);
3. an hourly ChronoSync backup of my main working folder (hours to months);
4. an hourly ChronoSync copy of my ~/Documents folder (hours to months);
5. a daily copy of my unified log files (days to months);
6. a daily clone of my Data volume and its external supplement (days to months);
7. a single clone of the System volume after each update to macOS (months).

So what happens if there’s a fire, lightning strike, flood, or all my gear gets stolen? This needn’t even be a disaster at the system’s location. A major fire nearby could prevent my gaining access to my Mac and its backups for many days, for example. So all the most important documents also need to be backed up to somewhere physically quite separate, ideally several miles or more away.

The most important decision is what needs to go to off-site backup. It’s fine for a sizeable business with a high-capacity Internet connection to make a complete nightly backup of its servers and their storage, but when you’re paying for it from your own shallow pocket that cost is likely to be prohibitive. For small and single-person businesses, families and individuals, off-site backup is every bit as important, just on different scale.

To a degree, iCloud sharing already covers some of the most important data which should be backed up off site: mail messages, address book, calendar, and keychain, in particular. If you don’t already share those in iCloud, consider doing so unless you already have good off-site backups of them. Then there are important records like tax returns and the documents to support them, and anything else which you really don’t want to lose. In my case, that includes a lot of source code, and all the articles I write for magazines.

Once you know what you want stored in your off-site backup, you’ll be able to work out what space you need. Couple that with how much you can afford to pay for the storage and service, and you should very quickly have a shortlist of solutions. I pay less than £/$/€ 1 per month for 50 GB of iCloud storage, which integrates well and is simple to use.

I’m sure I’m going to be deluged by personal recommendations in your comments, which I welcome. There’s one cloud service which I single out for its all-round excellence: Backblaze. Their services scale from backing up individual MacBooks, through unlimited capacity single computer backup from $60 per year, to large scale B2 storage similar to Amazon S3. It’s the benchmark against which you should judge all others.

Off-site backup doesn’t require a cloud service either. For many years before it became available, smart system administrators used a cunning trick which gave excellent off-site backup. This centres on a RAID system configured in ‘mirror’ formation, RAID Level 1 and its variants, in which the drives can be hotswapped, which results in the RAID system automatically rebuilding itself.

At the end of each day, the sysadmin pops one of the drives and inserts a freshly-formatted drive in its place. The system then automatically rebuilds the Level 1 RAID so that it replaces the drive that you’ve just removed from that RAID. That isn’t the sort of thing you’d want to do when the RAID system is active, and will probably take much of the night before the RAID is online again and ready for use. The removed drive is then taken off site, for example to secure storage in the sysadmin’s home, and the following day a third drive is taken in to use as the next off-site backup.

Although cloud backups are very popular now, they’re inherently less reliable than backing up to local storage. When disasters happen, infrastructure such as Internet connections is not only vulnerable, but it’s often in high demand by emergency and other services dealing with the disaster itself. It can be valuable for financial organisations and others which have fallback operating locations to which they can relocate in the event of their normal location being unavailable, but most small users won’t have the option of moving somewhere which is as well-connected to the cloud service. Without that connection to the cloud service, you can’t access or restore from your off-site backups.

Unless you design your backup system with considerable redundancy and fallbacks, off-site backup is never a substitute for local backup, but an adjunct and fallback. Unless you’re using iCloud, you’ll also need to consider what software to use. Options include Backblaze, IDrive and Acronis True Image Cloud for those respective services, and ChronoSync, which currently supports Backblaze B2, Google Cloud and Amazon S3 storage. Note that, even in Catalina, Time Machine can’t make its backups to iCloud, but that you can use Dropbox or Google Drive as you would iCloud Drive, if you prefer either of them.

This completes my current thoughts on backing Macs up, that is keeping copies of what is on their working storage so that you can restore items which become unavailable, whether a single document which gets inadvertently deleted, or a whole Mac which gets wiped or replaced. My next article in this series looks at the most difficult issue of all: archiving, in which you move completed projects to some form of ‘permanent’ storage.