duplicity-backup.sh

Foreword

Description

duplicity-backup.sh is a wrapper script derived from the dt-s3-backup.sh script of Damon Timm (http://damontimm.com/code/dt-s3-backup) and designed to automate and simplify the remote backup process of duplicity on Amazon S3 instances or other backup destinations (ftp, rsync, sftp, local file…).

See the README file hereafter for more information.

duplicity-backup.sh IS NOT duplicity

The official documentation of duplicity is relevant to duplicity-backup.sh too. Virtually any option supported by duplicity can be specified in the config file of duplicity-backup.sh. See the STATIC_OPTIONS, CLEAN_UP_TYPE and CLEAN_UP_VARIABLE parameters in particular.

Before asking something about duplicity-backup.sh, ensure that your question isn’t actually concerning duplicity ;) First, make sure you can perform a backup with duplicity without using this script. If you can’t make the backup work with duplicity alone, the problem is probably concerning duplicity and not this script. If you manage to make a backup with duplicity alone but not with this script, then there is probably a problem with duplicity-backup.sh.

The original mail command had a tendency of creating a few invalid 'To' addresses.
ie:To: SERVER3-backup@domain.com, -f@localdomain.local,
--@localdomain.local, THESPECIFIED@EMAIL.com,
SERVER3-backup@someotherdomain.com

I misunderstood your comment, the FTP_PASSWORD variable doesn’t go in STATIC_OPTIONS of course.
Duplicity’s official documentation states “Duplicity can also access a repository via ftp. If a user name is given, the environment variable FTP_PASSWORD is read to determine the password”.

In order to do so a simple FTP_PASSWORD="thepassword" followed by export FTP_PASSWORD in your personal config file should do the trick.

That seems to restore everything below the mentioned “rel/dir/path”. Would it perhaps include the defined top level directory (i.e. “startdir” in /rel/path/startdir), rather than restoring everything below it?

Yep, the command above seems to work OK to restore either a file or a directory. It restores everything down from the given directory (hence it’s a good idea to make sure that the target is either empty, or otherwise suitable location for all the files found in the directory defined to be restored :)). It seems then that the functionality for “–restore-dir” is already there, and it can, perhaps, be added as an alias to “–restore-file”). Suppose “–restore-file” could alternatively be renamed to “–restore-file-or-dir”, but that might break cron jobs and scripts that rely on the existing arguments.

it depends of the value of CLEAN_UP_TYPE and REMOVE_INCREMENTALS_OLDER_THAN variables in the config file.

Long answer:

The backup process and the cleaning process are distinct:

first a backup is done. The type of backup (full or incremental) depends on the status of the current chain of backup and of the backup parameters in the script (in particular --full-if-older-than in STATIC_OPTIONS)

then a cleanup is done in two steps :

first a cleanup done according to the cleanup parameters in duplicity-backup.conf (CLEAN_UP_TYPE and CLEAN_UP_VARIABLE) that are directly given to duplicity.

second, if and only if the REMOVE_INCREMENTALS_OLDER_THAN parameter in the config file is set, a cleanup of type remove-all-inc-of-but-n-full is done

I’m not sure what is exactly the use case you’re thinking about, but according to duplicity’s documentation if you swap the remote URL and the local path “Duplicity enters restore mode because the URL comes before the local directory.”

Note that I can’t help you more than citing duplicity’s documentation, duplicity-backup.sh being only a wrapper for duplicity, all the limitations of duplicity apply to the script…

Hey there, I’m trying to use this script (very nice and easy to use, thanks for sharing!) as an anacron job. I’m using GPG keys for signing and encrypting the backup, but the script does not run correctly as root since it can’t see the user’s gpg-agent. If I try to run as root (sudo su; ./run-script), I get this output on stdout. Any idea how to work around this and keep using GPG? It works flawlessly if I run the cron job as myself instead of root.

Well I have no idea what your script is actually doing (the “run-script”) so I have no clues here. I have no idea about your GPG keys setup either…

It looks like you have a common issue that consist of letting “cron” scripts access the gpg-agent keyring… But I have no experience with gpg-agent at all… so I’m sorry not being really able to help here.

If your problem is related to a bug in the duplicity-backup.sh script or if your problem can be solved by improving the script somehow I would be happy to hear about it and/or help to implement it :)

What I can do with it?
As I understand it from this line of script, but I don’t know what to do with it: cat ${LOGFILE} | ${MAILCMD} -s """${EMAIL_SUBJECT}""" $EMAIL_FROM ${EMAIL_TO} -- -f ${EMAIL_FROM}