You Are Only as Good as Your Next Resurrection (Part 2)

(NOTE: This is the second of a three part series on setting up a cloud-based backup system, and describes how to use the various technologies discussed previously. The first describes criteria and reasoning for the various technologies selected for use, while the third describes setting up the backups to run automatically on schedule.)

Setting Up “restic”

restic” is the the backup technology we will use for its performance, deduplication, and native support for writing to various different remote backends. You can install “restic” using the apt package manager:

$ sudo apt install restic

But I think it would be better to pull the latest version off their site, due to numerous little but useful improvements in this version vs. the ones in the Ubuntu repositories. It is Go language application that can be downloaded as a single-file statically-compiled self-contained binary for a variety of platforms.

Setting Up the Cloud Storage Service

Making Your First Backup with “restic”


“restic” can take all its arguments, options, and settings at run time. However, what we are going to do is to create a shell file that defines the values we need in some standard environmental variables, and we will source this file just before running any backup or backup management operations. This makes running restic as simple as, e.g., “restic init” instead of “restic init -r s3:https://url/of/repo” etc., as “restic” will just look to these variables for the information that we need. Note that you do not need to leave all these variables in there if you feel uncomfortable having them around: you can just supply them as needed. The variables you will need to define vary depending on whether you are using Wasabi or Backblaze:

  • Wasabi: Create and obtain your access ID and key pair, following these instructions Then, create your directive file that populates the appropriate environmental variables, e.g., “~/.backup-configs/”:

    export AWS_ACCESS_KEY_ID="your-Wasabi-Access-Key”
    export AWS_SECRET_ACCESS_KEY="your-Wasasbi-Secret-Key”
    export RESTIC_REPOSITORY="s3:"
    export RESTIC_PASSWORD="speakfriendandenter"
  • Backblaze: After [setting up your B2 account](), you need to obtain your B2 account identifier and key. Then, create the directive file to be sourced, e.g., “~/.backup-configs/”:

    export B2_ACCOUNT_ID=gobbledegook
    export B2_ACCOUNT_KEY=jabberwocky
    export RESTIC_REPOSITORY="b2:test-js-2018-07-07"
    export RESTIC_PASSWORD="speakfriendandenter"

Repository Creation

  1. Source the repository directive files to populate the environmental variables with all the information that “restic” needs;

    $ . ~/.backup-configs/
  2. Create the backup repository using the “init” command. As we have exported the environmental variables specifying (1) the access identifier; (2) the access key; (3) the repository URL; and (4) the repository password above, the command is very simple. Otherwise we would have to specify these values as arguments, options, or enter them in when prompted.

    $ restic init

    Also note that you could manually create the cloud storage bucket, but “restic” will also automatically create one for you if it does not exist.

  3. Create the first “snapshot” using the “backup” command (note that the “–verbose” flag does not work in the older versions of “restic” available from the Ubuntu repositories as of 2018-10-10), with path(s) to the directories on our local system that we want to backup.

    $ restic backup --verbose ./phylogenetics ./aviation
  4. Check the backup using the “snapshots” command:

    $ restic snapshots

Making Subsequent Backups with “restic”

  1. Simply re-run the backup command to take another snapshot:

    $ restic backup --verbose ./phylogenetics/
  2. And check to make sure it there:

    $ restic snapshots

Mounting the Remote Backup

As the saying goes, “amateurs talk about backups, professionals (or the old souls) talk about restoration”. Your backups are useless if you cannot get to them easily. Of course, you can always restore the entire backup (or the latest snapshot) through “restic”, and this is covered in the guide I mentioned above as well as the restic documentation. But what I am going to talk about here is ability the mount the remote backup in a local file system.

Folks, this is really, really, really, really, really COOL!

Instead of downloading the entire backup (which you only really need to do in the event of a full machine/disk loss), you can mount the backup as a local directory, browse through the files and view/copy just the directories/files you need.

$ mkdir /media/restic-test
$ restic mount /platform/media/restic-test/

I will say, however, that I do prefer Borg’s way of handling mounting. “restic” runs in blocking mode in the shell, requiring you to open up another shell session to get to the files and then return to the first shell and send a Ctrl-C to exit. The Ctrl-C unmounts the drive and cleans up … IF you have no other process using the drive, including a shell session that you forgot about. If the latter is the case, then things get into a dirty state, and you have to force an unmount by one of the following:

# Linux
fusermount -u /path/to/local/mount
# macOS
umount /path/to/local/mount

In this respect, Borg seems to do it right: running the mount command mounts the drive and exits right away, freeing the same shell session for you to do other things including browse the files. And unmounting is a lot cleaner as well.

More …

  • Part 1: what programs/technologies to use, and why.
  • Part 3: scheduling the system to run for automatic backups.