Backup and restore

1

Hey! After reviewing the documentation, I realized that it does not contain anything about backup and restore of the configuration, users and other things about the backup process, who can advise?

1 Like
2

@sudouser We have plans for a firezone-ctl backup and firezone-ctl restore command in our backlog.

For the time being, something like this should probably work, but I haven’t tested it extensively:

Backup:

# Stop postgres
firezone-ctl stop postgresql

# Backup
tar -zcvf firezone-backup-$(date +%s).tar.gz \
  /etc/firezone \ # Configuration
  /var/opt/firezone # Data

# Start Postgres
firezone-ctl start postgresql

Restore:

# Unpack Firezone
dpkg -i firezone*.deb

# Restore
tar -zxvf firezone*.tar.gz -C /

# Reconfigure
firezone-ctl reconfigure
3

looks good but i think the postgres data might get corrupted if i copy it without stopping the service

4

True – it’d be helpful to do a firezone-ctl stop postgresql beforehand. I’ve edited to add. Thanks!

1 Like
5

@jamil if db is moved to AWS RDS, is the data location still required to do backup? or just having backup of /etc/firezone folder is enogh? From my understanding if DB data is not getting created on server, all other data gets generated according to what is mentioned in firezone.rb file?

6

@utsavk You’ll still want to backup the directories listed here as they contain private keys and other sensitive data not stored in the db:

Let me know how that goes and if you hit any snags! :slight_smile:

7

Just wanted clarity of the process, the private keys and secrets are in file: /etc/firezone/secrets.json file.

The other files mentioned here:

  • /opt/firezone/embedded
  • /opt/firezone/sv
  • /usr/bin/firezone-ctl
  • /etc/systemd/system/firezone-runsvdir-start.service
    All the above are automatically setup when I install Firezone for restore, and I didn’t find any other file mentioned here: File and Directory Locations | Docs Firezone which has secrets.

So after installation, if I just restore the files in /etc/firezone, and restore my DB, everything will work, please correct me if I am wrong?

8

@utsavk Sorry – you’ll need to backup/restore the following:

/opt/firezone
/etc/firezone
/var/firezone
/usr/bin/firezone-ctl
/etc/systemd/system/firezone-runsvdir-start.service

I’ve opened a PR which clarifies this better: Clarify file and directory locations by jamilbk · Pull Request #682 · firezone/firezone · GitHub

I haven’t tested this, but that should be all the data you’ll need. You may need to re-enable the firezone-runsvdir-start service after restore (config for this is tracked by systemd itself).

9

Thanks @jamil
What we did to test out restore:

  • Took backup of DB
  • Took backup of /etc/firezone directory
  • Restore DB
  • Install Firezone
  • Restore files in /etc/firezone
    Worked like a charm
10

Great, thanks for the update! cc @jason – let’s add this to the docs!

11

Hi,

I am using duplicity to backup my VPN servers (backing up to Dropbox). For backing up the database, I am using pg_dump and dumping it to a file and backing that up rather than stopping Firezone to get a consistent copy.

A dump can be taken like this:

/opt/firezone/embedded/bin/pg_dump \
  -U firezone \
  -d firezone \
  -h localhost \
  -p 15432 > "/path/to/dump/to/firezone.sql"

You can then backup the .sql file in addition to the other directories noted. A complete copy of the backup script I use for duplicity is:

#!/bin/bash

## Set temporary backup directory (used for postgres backup)
BACKUP_DIR="/opt/backup"

## Terminate if any command fails
set -e

## Source variables
source /root/.duplicity

## Create backup directory if not existing
if [ ! -d "$BACKUP_DIR" ]; then
  mkdir "$BACKUP_DIR"
  chmod 0700 "$BACKUP_DIR"
fi

## Dump database
/opt/firezone/embedded/bin/pg_dump \
  -U firezone \
  -d firezone \
  -h localhost \
  -p 15432 > "${BACKUP_DIR}/database.sql"

## Remove old backups
duplicity \
  remove-older-than 360D \
  --force \
  rclone://dropbox:/Duplicity

## Run backup
duplicity \
  --verbosity info \
  --encrypt-sign-key="$GPG_KEY" \
  --full-if-older-than 90D \
  --asynchronous-upload \
  --log-file "/var/log/duplicity.log" \
  --include '/etc/nftables.conf' \
  --include '/etc/nftables' \
  --include '/root/.zsh_history' \
  --include '/root/.bash_history' \
  --include '/opt/backup.sh' \
  --include "${BACKUP_DIR}" \
  --include '/etc/letsencrypt' \
  --include '/etc/firezone' \
  --include '/var/opt/firezone/etc/env' \
  --include '/var/opt/firezone/nginx' \
  --include '/var/opt/firezone/ssl' \
  --include '/var/opt/firezone/cache' \
  --include '/opt/firezone' \
  --exclude '**' \
  / \
  rclone://dropbox:/Duplicity

## Remove database dump
if [ -f "${BACKUP_DIR}/database.sql" ]; then
  rm -f "${BACKUP_DIR}/database.sql"
fi

## Cleanup
duplicity \
  cleanup \
  --force \
  rclone://dropbox:/Duplicity

## Unset variables for safety
unset GPG_KEY
unset PASSPHRASE

Note: I use rclone which in turn has the Dropbox backend setup; this is because Dropbox changed their access tokens to be short lived which Duplicity does not seem to handle.

This does need some other setup steps to make the script work if you want to use it (eg. you would need to generate GPG key, put in environment file, Dropbox app creation, setup rclone etc.) and I am happy to detail those more if its useful for you.