Restic Backups on Backblaze

I’ve always used rsync and openrsync(1) to backup my systems since they’re ubiquitous, but recently I’ve been wanting something that supports the S3 protocol so I can use providers like Backblaze. While rclone sounds like the obvious choice, I went with restic because it has:

• Chunk-level deduplication, meaning a chunk of data is only stored and transferred once.
• Snapshots to easily reference multiple versions of a filesystem.

Using Restic with Backblaze

Backblaze has very economical pricing at $6/TB/month and supports both the B2 and S3 protocols. (As an aside, they also publish their drive statistics which is useful when buying drives.)

When using restic with Backblaze, restic recommends using the S3-compatible API due to error handling issues in the library they use for B2.

Creating a Backblaze Bucket

After creating an account, click on “Buckets” in the navigation menu to create a bucket. Since restic encrypts everything with its own key, encryption is redundant unless you’re also using the bucket for something else.

Note down the endpoint to use for connecting to it later.

Creating a Backblaze Application Key

To create an application key, click on “Application Keys” then “Add a New Application Key”.

While using the same repository for everything would be a benefit as far as deduplication, it’s best to isolate different systems with different keys/repositories to prevent one compromised system from accessing everything. Depending on the situation, isolating each host this way is a reasonable compromise. For example, to create a key for “host1”, use the filename prefix host1/restic.¹ Similarly if you don’t need access to multiple buckets, limit access to only the one you need by setting bucketName (seen below).

Make sure to save the application key somewhere, because Backblaze only displays it once, at creation.

Restic Encryption Keys

On the client side, restic will need an encryption key. There are four methods of loading keys:

1. Password command specified with --password-command or RESTIC_PASSWORD_COMMAND.
2. Password file specified with -p or RESTIC_PASSWORD_FILE.
3. RESTIC_PASSWORD environment variable.
4. From the terminal.

The first two methods are best since environment variables aren’t very private and the fourth method doesn’t allow for unattended use. To create a password file, run something like this as root:

mkdir /etc/restic

# Allow read-write by owner only, then set owner:group
chmod 600 /etc/restic/key > /etc/restic/key
chown root:wheel /etc/restic/key

# Write key
echo 'encryption key' > /etc/restic/key      

Or if restic doesn’t need to be run as root, use a user-owned key instead. Remember to save this encryption key securely in another location, because if it’s lost you cannot access the repository.

Running Restic & Restic Configuration Managers

Since restic doesn’t have any configuration files, you’ll want some system of loading keys and other information. There are tools to add configuration files to restic, namely resticprofile. However, before learning about resticprofile I created resticc—a simple script to load keys and repository locations from configuration files—so I haven’t tried resticprofile yet. Alternatively, it can be as simple as hardcoding the information in a script, for example in “restic-env”:

#!/bin/sh

export AWS_ACCESS_KEY_ID=005aabb3462e52b0000000008
export AWS_SECRET_ACCESS_KEY=$private_key

host=s3.us-east-005.backblazeb2.com
bucket=backup-964f
restic -r s3:https://$host/$bucket/host1/restic \
	-p /etc/restic/key "$@"

Then the script can be used to initialize the repository and create a snapshot of “~/src” as shown below:

$ restic-env init
$ restic-env backup --tag=src ~/src

Once setup, restic can be used with scheduling systems like cron(8) to regularly perform backups, delete excess snapshots, and remove unused data.

For more details on restic usage see the manpages and website.