Welcome to part II on Backups! We covered the following in part I:

Why performing backups are important skills for Cybersecurity professionals
Setting up an Ubuntu Desktop machine with files to backup
Setting up an Ubuntu Server machine to receive the backups
Using Duplicity to perform backups
Creating GPG keys to encrypt the backups
Creating a backup script

This lesson will cover sending backups offsite, retrieving the backups, and performing additional automation.

Begin by switching to the backup user on Machine 1 (Ubuntu Desktop)

sudo -i -u bkup

Now create a file for your offsite backup script:

touch ~/backup.offiste

chmod u+x ~/backup.offsite

vim ~/backup.offiste

Add this to ~/backup.offsite

#!/bin/bash

ENCRYPT_KEY=<Encrypt Key you used from Part I>

#B2 INFO

KEY_ID=<B2 KeyID>
APP_KEY=<B2 applicationKey>

BUCKET_NAME=<B2 bucket name>

# BACKUP DETAILS

APPLICATION_NAME=/opt/backups/duplicity/backup_me

BACKUP_FOLDER=/home/bkup/backup_me

###[BackBlaze Backup]#############

# Perform Backup. Full backup if older than 2W

duplicity --encrypt-key ${ENCRYPT_KEY} \
       --full-if-older-than 2W \
       ${BACKUP_FOLDER} \

       b2://${KEY_ID}:${APP_KEY}@${BUCKET_NAME}/${APPLICATION_NAME}

#Only keep 2 full local backups
duplicity --encrypt-key ${ENCRYPT_KEY} \
        remove-all-but-n-full 2 --force \
        b2://${KEY_ID}:${APP_KEY}@${BUCKET_NAME}/${APPLICATION_NAME}

#Cleanup failures
duplicity cleanup --force \
        --encrypt-key ${ENCRYPT_KEY} \
        b2://${KEY_ID}:${APP_KEY}@${BUCKET_NAME}/${APPLICATION_NAME}

You need to fill in four things:

ENCRYPT_KEY (this is in the backup.local file from part 1)
BackBlaze KEY_ID
BackBlaze APP_KEY
BackBlaze BUCKET_NAME

You need a free account with BackBlaze to fill in the last 3 values. The first 10GB on BackBlaze is free- it costs nothing to follow along. Go ahead and sign up:

https://www.backblaze.com/b2/sign-up.html

A bucket is a container that holds data. Here’s how it should be set up:

The name must be unique to all other buckets on Backblaze. It’s OK for all the other options to be defaults. We don’t want to enable encryption, because we’re already doing this with the GPG keys.

Create your bucket. Now click “Application Keys” on the left pane.

Then click “Add a New Application Key.” Name the key whatever you want. Allow access to the name of the bucket you created earlier. Here’s what mine looked like:

Note: You can’t complete the tutorial if your applicationKey has a “/” in it. The b2 tool we’re going to install won’t parse through our bash script properly.

To work around this, delete your keys and regenerate them until you get one without a “/” (it’s never taken me more than two attempts.)

You will now see the keyID, keyName, and applicationKey. Don’t log out of this page yet, because the application key will only appear there once.

Vim ~/backup.offsite and fill in the values:

KEY_ID = keyID
APP_KEY = applicationKey
BUCKET_NAME = Name for the bucket you made

Mine looks like this:

Save the changes and switch back to the original user (not the bkup user). Install these dependencies using apt. The script will be ready to run!

sudo apt update
sudo apt install python3-pip
sudo pip3 install b2sdk==1.7.0

Now run the script as the bkup user:

Head to BackBlaze and check the bucket you created. You should see your backup files there!

Nice work. Remember that the optimal backup depends on your situation, tools available, and compliance requirements.

If you’re interested in other methods for completing offsite backups, I suggest exploring these:

Use Azure Cloud Blobs or AWS S3 Buckets
Backup to an Ubuntu Server VM on a Platform like Digital Ocean or AWS
Put your backups on a hard drive and store them in another town

Restoring Your Backup

Backups have 0 value if you can’t restore them. If your backups are corrupt, you spent time and money on storage space that gives you no benefit. It’s important to test backups on a regular schedule.

Before you can retrieve your backup, you need to know the basics of public key cryptography. When we generated our GPG keys in Part 1, there were two of them- a public key and a private key.

The public key can be handed out to anyone. The private key must remain a secret, though. It’s the only key that can decrypt your backups. Remember these two rules:

Public Key: services and people can encrypt messages using this public key. You can hand it out.
Private Key: This key decrypts messages encrypted with the public key. Only you should know about and see this key.

We’re going to restore our backup on Machine 1 (Ubuntu Desktop). We’ll restore using the “bkup” duplicity user.

First, we need to export the private key from the sudo user and import it to the bkup user.

Open a terminal and ensure you’re the user that created the GPG keys. Run these commands:

gpg --export-secret-key -a <email you used> > private.key

mv private.key /tmp/private.key

sudo chown bkup:bkup /tmp/private.key

Now as the “bkup” user:

gpg --batch --import /tmp/private.key

rm /tmp/private.key

Now you can run the restore command:

duplicity restore sftp://<machin2ip>//opt/backups/duplicity/backup_me /tmp/backup_me

This command restores the duplicity backup from Machine 2 using the most recent full backup and following incremental backups.

It then drops the files and folders into the /tmp/backup_me directory. It automatically creates the “backup_me” folder on Machine 1.

You may see an output that says “[Errno 1] Operation not permitted.” It’s OK to ignore those errors- they happen when Duplicity attempts to set permissions on the files it’s restoring.

Now look into /tmp/backup_me. You’ll see your files!

Automating The Backups

We now have two backup scripts that use Duplicity. One backs up to another machine on the local network. The other backs up to BackBlaze.

You don’t want to think about manually running these scripts each day- let’s automate this task.

Enter cron. Let’s create a cron job that will run these scripts at a specific time.

Before creating a cron job, I use crontab.guru to get code that designates when the job will run.

Head to the site. In the grey rectangle, indicate when you want your cron job to run.

The image above says “Run at 11 PM every day of the month and each of the week.”

Now run this command as “bkup”:

crontab -e

The terminal will prompt you to select an editor. Pick vim.

Add this to the end of the cron file:

As you can see, I pasted the values from crontab.guru and then entered the path to the script.

The first line runs the backup.local script at 11 pm each day.

The second line runs the backup.offsite script at 11:05 pm each day.

Save the file and exit. You’ll see the message “crontab: installing new crontab” in the terminal.

Nice work! Now your backups will run each night (if your machine is on.)

You can always use this command to check the status of your backups:

duplicity collection-status --encrypt-key <key here> sftp://<ip>/<backup location>

Nice work! Before closing, I’d like to mention that these two lessons covered backups on Linux machine.

Remember that an organization likely has data to backup on multiple devices (Windows servers, Mac desktops, mobile devices, etc.) Each might require different strategies.

That’s all for now. Thanks for reading!

Intro to Backups, Part II: Restoring Backups

Restoring Your Backup

Automating The Backups