duplicity backup - email notifications

This is one post in a series of tutorials on Duplicity. If you are just getting started with duplicity, I recommend to first read the first and second part to get a basic overview of duplicity and get GPG keys setup properly (this will not be covered in this post). You should also visit the duplicity overview post, which contains a list of all posts in this series. The basic configuration of this post will be used in this post to configure duplicity-backup.sh.

Email notifications

When relying on a backup system it is important to be confident that everything worked. The easiest solution to accomplish this is by testing your backup on a regular basis, and by getting notified if something goes astray. The duplicity backup script does offer several notification methods for notifications, email, Slack, pushover, IFTTT and Telegram.

This post will focus on email notification setup as almost everyone uses email, whereas other services have a more specific target audience.

Setup is similar for each of the notification services - simply filling in the variables in the configuration example for the service you’d like to use.

Note: While this covers E-mail notifications, I would recommend to rely on IFTTT for notifications - the setup is simpler than for email as explained in this post.

Email configuration

To have a working email notification, we first need to configure our system to be able to send emails. On Debian, the default is exim4. If you already have your system configured to send emails, then you can skip to the next section, otherwise read on - it won’t take long.

Let’s start by reconfiguring exim4

sudo dpkg-reconfigure exim4-config

The setup will guide us through the configuration. We will only configure outgoing emails and have the server listen on localhost only.

The only 3 settings we need to change are “General type of mail configuration: " to “internet site; mail is sent and received directly using SMTP”.

duplicity_email1

, “System mail name: " to your domain name and

duplicity_email2

“IP-addresses to listen on for incoming SMTP connections:” to 127.0.0.1 to make sure the SMTP server is only listening on localhost. Otherwise, we would have an open SMTP server, and it would not take long until it is abused to send Spam emails.

duplicity_email3

All other settings can remain at default assuming you did not already configure this previously.

Now, we can run a test by sending an email to our email address:

echo "test Email" | mailx -s "test email 1" [email protected]

Check your mailbox (also the Spam folder) for an email with “test email 1” as subject. You should receive it within minutes if everything is working correctly.

Script configuration

Open the configuration we created in this post and search for EMAIL. Change the following settings to your preference (your email address, and a custom subject if you’d like to change it from the default duplicity-backup Alert ${LOG_FILE}.

[email protected]
[email protected]
EMAIL_SUBJECT=
#EMAIL_FAILURE_ONLY="yes" # send e-mail only if there was an error while creating backup
EMAIL_FAILURE_ONLY="no" # always send emails

I changed the setting EMAIL_FAILURE_ONLY to always send me an email (so i am sure the backup ran). This is also useful to test the settings - if the first email would be sent when the backup fails we cannot be sure sending mails actually works as we never tested it.

Now, run the script again and check your mailbox afterwards.

./duplicity-backup.sh --config duplicity-backup.conf --backup

The script output should end with “Email notification sent to [email protected] using mailx” If the configuration was correct, you should have received an email. Don’t forget to check the Spam-folder - depending on the email provider the email may be detected as Spam (we did not set the server up to deliver safe, verified emails - so the authenticity of the email is not guaranteed - as the sender address is known (configured above) we can whitelist to get the emails regularly).

No matter what notification you configure - configure at least one of them so you are aware that the backup failed and needs manual interaction / checking.

The best backup-strategy is worthless if it fails to backup silently or the backup is never tested, so please use either this or the other method to get notified of problems with the backup.