Thu, 02 Nov 2017

Restic Systems Backup Setup, Part 3 - Setting up a client

This is Part 3 of my series on building a restic-based system backup series. The rest of the articles can be found here.

We've got enough things setup that we can start backing up a client system. We'll do this in two sections: setting up the server side, and setting up the client side.

Setting up the backup server side

Using 'new-restic-server' to set up the server

You can find new-restic-server in the git repo.

/backups/bin/new-restic-server -H aclient.example.com -p 9002

will set up all of the per-client setup on the backup-server: making a minio config and path for storage, setting up a runsv directory to run the minio server, and creating access key and secret for the minio server. You will have to make sure the port you picked (in this example, 9002) is distinct between all clients backing up to this service.

Activing the minio server

Activating the minio server is a distinct step, but an easy one with our runsvdir setup:

ln -s /backups/systems/aserver.example.com/conf/runsvs/minio /backups/systems/conf/runit/aserver.example.com-minio

A few seconds later, runsvdir will detect the new symlink and start the minio process.

Setting up the client side

Installing the binaries

I install these all in /usr/local/bin, you'll need to get a recent copy of restic, as well as the daily-restic-backups, restic-unroll and restic-wrapper scripts from the client directory of the git repo (handily linked at the end of this article).

Configuration

First, make an /etc/restic configuration directory: sudo install -o root -g root -m 700 -d /etc/restic

Create the environ file

/etc/restic/environ contains a series of environment variables that the restic client will use to identify the repo to backup to, as well as the access keys for it. It looks like the following:

export AWS_ACCESS_KEY_ID=key goes here
export AWS_SECRET_ACCESS_KEY=secret key goes here
export RESTIC_REPOSITORY=s3:https://backup-server.example.com:9002/backups
export RESTIC_PASSWORD_FILE=/etc/restic/repo-password
    

Most of these are self-explanitory. The RESTIC_REPOSITORY is marked as s3 because that's what minio looks like to it. It ends in /backups because you have to put things in a "bucket" RESTIC_PASSWORD_FILE causes restic to read from that file, instead of prompting for a password.

Create include and exclude files

Now the hardest part, deciding what to backup and exclude. Everything will be backed up from /, use full paths in the include an exclude files, which go in /etc/restic/include-files and /etc/restic/exclude-files respectively.

Configure repo password

sudo /bin/sh -c 'pwgen 32 1 > /etc/restic/repo-password'

Here, we're using the pwgen command to generate a single, 32 character long password. YOU MUST NOT LOSE THIS. This is the encryption key used to encrypt everything in the repo, and without it, you won't be able to recover anything. I store mine in a GnuPG encrypted git repo that I backup outside of my restic setup.

Initialize the repo

sudo /usr/local/bin/restic-wrapper init

will initialize the repo. It will spit out something like:

created restic backend bcae9b3f97 at s3:https://backup-server.example.com:9002/backups Please note that knowledge of your password is required to access the repository. Losing your password means that your data is irrecoverably lost.

Set up a cron job to do daily backups

backups-cron.d contains a useful cron.d snippet to perform daily backups, modify to your taste.

Conclusion

We now have a client system which backs up daily to a backup server storing data in minio. Future articles will talk about automated replication to additional repositories for redundancy.

As a reminder, you can find the canonical repository of all my utility scripts in this series here. You can also find them at github.

Posted at: 10:40 | category: /computers/backups/restic-systems-backups | Link