Ben Owen

Full time nerd. Professional eater of cake.

Building My Home Server (Part 3 - Back up NAS to offsite server)

My previous two posts (part 1, part 2) have covered setting up a local NAS and an offsite backup server. This post will discuss how to back up data from the NAS onto the remote server.

Backing up from Unraid to off-site Linux server

rsync stands for "remote sync" and is similar to robocopy on Windows. It can be configured to use SSH for secure file copies across public networks. There is a slight hiccup with this, due to the way Unraid handles SSH keys. I followed this blog post to create a persistent key vault and generate public / private key pair.

My rsync backup command looks like this:

rsync -a -h --progress --rsh="ssh -l remoteuser -i /mnt/user/ssh_vault/backup.example.com" /mnt/user/backup remoteuser@backup.example.com:~

The command line options break down as follows:

  • -a - Archive
  • -h - Human readable
  • --progress - Show progress indicator
  • --rsh="ssh -l remoteuser -i /mnt/user/ssh_vault/backup.example.com" - Use SSH for the remote connection. The section in quotes is the SSH command line that will be used. -l remoteuser specifies the remote username (remoteuser in this case), and -i /mnt/user/ssh_vault/backup.example.com specifies that we'll use the private key from the vault created previously in order to authenticate
  • /mnt/user/backup - source directory to copy
  • remoteuser@backup.example.com:~ - destination directory (the ~ signifies the user's home directory)

In order to ensure that only one backup operation can be started at once, I wrapped this with flock (file lock utility):

flock -n lock_file -c "rsync -a -h --progress --rsh=\"ssh -l remoteuser -i /mnt/user/ssh_vault/backup.example.com\" /mnt/user/backup remoteuser@backup.example.com:~"

The flock options used here are:

  • -n - non-blocking, causes an immediate exit if the lock is already held
  • lock_file - creates a file in the current directory called lock_file. The lock will be held on this file (which will be created if it does not already exist)
  • -c - everything following this is the original rsync command. Note the quotes around the --rsh option now need to be escaped with backslashes.

Some additional resources:

Persisting SSH configuration

When running rsync for the first time, a prompt appears which has to be accepted by the user.

The authenticity of host 'backup.example.com (93.184.216.34)' can't be established.
ECDSA key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ordinarily, this wouldn't be much of a problem, but because Unraid does not persist the SSH known_hosts file across reboots, we need to get a bit creative.

  • Answer yes to create the known_hosts file
  • Copy the SSH config to the Unraid config folder
    cp -r /root/.ssh /boot/config/sshroot
    
  • Add the following to /boot/config/go :
    # Restore SSH configuration and set permissions
    cp -r /boot/config/sshroot /root/.ssh
    chmod g-rwx,o-rwx -R /root/.ssh
    

Scheduling the backup

Open /boot/config/plugins/dynamix/remote_backup.cron in your preferred text editor, e.g.

nano /boot/config/plugins/dynamix/remote_backup.cron

Add the following content and save:

# rsync backup at 2am daily (if not already running)
00 2 * * * flock -n lock_file -c "rsync -a -h --progress --rsh=\"ssh -l remoteuser -i /mnt/user/ssh_vault/backup.example.com\" /mnt/user/backup remoteuser@backup.example.com:~"

Note the trailing linefeed at the end of the file!

Unraid adds the content of .cron files inside /boot/config/plugins/dynamix/ to the crontab dynamically on system boot (or after running update_cron, which you will probably want to do now). You can check that your job has been added to the crontab using cat /etc/cron.d/root.

Continue reading: Part 4 - Blocking Ads with Pi Hole