Posted in Miscellaneous

Backing up a Mac is a solved problem, right? Just attach an external drive for Time Machine and sync your files to iCloud. But what if you don’t want to have an external drive hanging off your laptop? Or if you don’t want to store all your files on iCloud? I didn’t want either, so I came up with a different strategy, which involves Carbon Copy Cloner, a NAS, rclone, and Backblaze.

Step 1: Backups to our home NAS with CCC

Time Machine is the built-in backup solution and it is not limited to storing the backups on an external drive. It can use an AirPort Time Capsule, too. The actual hardware products have been discontinued many years ago, but the process is still supported. Even better, there are different solutions that allow Unix-based servers to act as Time Capsules. Openmediavault, the software running our home NAS, makes this relatively straight-forward, too.

That said, my experience with Time Machine wasn’t great. It backs up files once an hour, and over a network this is a slow process, which tends to impact network performance on the laptop. This is the case even with super-fast Wifi and gigabit local networking. And while there are some cases where hourly backups can be useful—an rm -r in the wrong directory for example—neither I nor the rest of the family have found hourly backups important. A backup that happens at night, when the laptop isn’t in use, would not only be sufficient, but it would also be preferable. Unfortunately, though, Time Machine doesn’t really give you any configuration options.

Enter the picture Carbon Copy Cloner (CCC), which offers all the configuration options a geek could ask for, and probably more. I set it up to back up the home directories of our laptops every night on a schedule that should only see one laptop at a time doing a backup. I write should because there’s no guarantee that a laptop will complete the backup in the one hour window it’s given. It usually works, though.

The backup only covers our home directories because that’s where the data we care about is stored. This makes the backups a good deal smaller than full-disk backups, and having to spend a couple of hours reinstalling the OS and applications if a laptop really breaks or is lost/stolen seems like a sensible trade-off for smaller backups.

One thing I haven’t written about is where exactly the backups are stored. For each of our home directories, no matter which laptop they come from, there is a disk image on a file share on the NAS. That share is named “Backups”, and the disk images generally have the same name as our usernames. In the screenshot at the top of the post, which shows the CCC backup task for my home directory, you can see that the destination is “erik.sparsebundle” on “Backups”.

In the screenshot you can also see a shield with the letter C in it. That signals that CCC will keep some old files around, similar to the history kept by Time Machine. The yellow symbol indicates that the backup file share isn’t mounted, but when running a backup CCC can (and will) mount the file share and then the disk image on that share.

The disk images are password-protected and encrypted, so that even if someone were to gain access to the NAS share, they wouldn’t be able to access the backup data. CCC stores the passwords for both, the share and the disk image, in the local keychain on the laptop.

The NAS, by the way, uses large, spinning hard disks in a RAID configuration. I am aware that a RAID is not a backup but backing up to a RAID ensures that our backups are safe even when a disk fails in the NAS.

Step 2: Offsite backups to Backblaze with rclone

So far we’ve covered the scenarios that are more likely to happen—even though I hope, of course, they won’t happen. But what if the laptops are at home, with the NAS, and then something bad happens, a burglary or a fire? I know at least one case where someone had their laptop and backup disks stolen from their home. Granted, this is unlikely, but if it were to happen at least there would be some comfort knowing that important documents, photos, and videos are safe. The obvious response to such a scenario is an offsite backup.

With the strategy from step 1 we already have disk images stored on the NAS. Now we just need to get those images to some place in the cloud. And because the disk images are password-protected and encrypted locally we don’t even have to particularly trust the cloud storage provider or rely on their encryption options.

When researching different providers, I found Backblaze. They seem to be a reputable company, they have significantly cheaper storage plans than the usual suspects like Dropbox or OneDrive, or storage options at AWS, GCP and Azure, and they offer an EU storage location. To clarify: I did not go for any of Backblaze’s backup products. All I needed was a place for the disk images, and the B2 Cloud Storage product is the best fit for that.

Backblaze uses so-called buckets to group related files and authorize access to them. For my backup purposes I created a private and unencrypted bucket using the web interface as shown below.

Access to the web interface of Backblaze can (and should!) be secured with two factor authentication. This is good for security, but it poses a problem for automated backups. Like many other systems, though, Backblaze offers application keys with limited rights for such cases.

The last piece of the puzzle is the process of getting the disk images into the cloud and keeping them updated. It would clearly be impractical to copy several hundred gigabytes of data for each disk image each time the image is pushed to the offsite location at Backblaze. Luckily, the file format Apple uses for the “sparse bundle” disk images divides the disk image into so called bands that are 8MB each, and the vast majority of band files doesn’t change when changes are made to the contents of the disk image.

My tool of choice to copy the files from the NAS to the cloud is rclone, a general tool to manage files on cloud storage. It supports many storage products, including Backblaze’s B2 cloud storage, and the configuration for my use case is straight forward. The cloud location is specified in a config file.

[backblaze]
type = b2
account = <my account id>
key = <the application key>
hard_delete = true

The name “backblaze” is the name I gave that location. The fact that the destination is Backblaze’s B2 Cloud Storage product is set in the type field. Other storage solutions have different, and sometimes more complicated configurations.

With this setup a simple script can be used to run the copy process. Note that I wrote the script in such a way that the name of the disk image is provided as an argument to the script.

#!/bin/sh

export SRC="/srv/dev-disk-by-label-data/backups/_Offsite/$1.sparsebundle"
export DST="backblaze:mimas01/$1.sparsebundle"
export BTT="01:00,4M 07:00,2M"

rclone --bwlimit "$BTT" --transfers 4 sync $SRC $DST

The SRC variable simply specifies the absolute path of the disk image on the NAS. (The script runs on the NAS.) The destination, given in DST, comprises the location name from the config, the name of the bucket, and then the name of the disk image in the cloud. The BTT variable holds timetable information. It’s set up so that rclone uses a maximum of 4MB/s from 1am to 7am, and 2MB/s for the rest of the time.

The final command in the script invokes rclone’s sync subcommand with the timetable and an option to run four transfers in parallel. There doesn’t seem to be general advice for the best number of parallel transfers. I found that for my context four was the magic number.

Step 3: Recovering data

With access to the NAS it’s easy to recover files simply by opening the respective disk image in Finder. For the offsite case there are multiple options, including Backblaze shipping a hard drive with the disk images by mail. More likely, though, you would simply download the disk images from the web interface.

This leaves only one pitfall: In a case where we would need the offsite backup, both, the NAS and the laptop(s), would be gone. But where again were the keys for the encrypted disk images stored? In the keychain on the laptops. So, it’s super important to keep those keys in yet another location. I use KeepassXC/Strongbox and sync my password databases between laptop and phone using iCloud. So even without a laptop, I would still be able to access Backblaze and the disk images stored there.