The recent take-down of codespaces got me thinking about off-site backup processes (which I currently perform manually with password entry). I have been reading tutorials showing how to automate backups through duplicity. These tend to revolve around using an SSH key to automate the authentication process to the backup server.

However, this seems full of holes to me. If the server being backed up is compromised to the point where the malicious user has gained access then they could automatically login to the backup server and remove the backups. Assuming that the admin used /usr/bin/nologin in the /etc/passwd file for the backup user (I have no idea how much this can be relied upon or if it would prevent duplicity from working remotely anyway), then the malicious user could still get duplicity to wipe the backups by using the duplicity remove-older-than [time now] command.

Is the only safe solution to send the files to the backup server using rsync over ssh and have a "master user" on the backup server perform local iterative backups of all the user accounts to its own storage area (e.g. only it has permissions to its own files, but it has permission to read all the other accounts files)? Or is there a way to prevent duplicity from removing backups and prevent remote login?

2 Answers 2


AFAIK duplicity can't do a backup of a remote directory to a local directory. I solve the problem in two steps. On the backup server do:

  1. Run rsync over ssh using ssh keys to sync the remote directory to a local directory

    rsync -avz -e ssh user@remote:/remote/directory local_directory

  2. Run duplicity from one directory to another. Use asymmetric GnuPG keys, so you don't need passphrases during encryption.

    duplicity --encrypt-key=YOUR_KEYID local_directory file://backup_directory

or without encrypting the backup:

duplicity --no-encryption local_directory file://backup_directory

After uploading the backup you can use chattr +i to make them immutable so they can not be modified or deleted. Only root can set or clear this flag.

As an alternative you could chown the files to another user after upload so that the backup account no longer has access to them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .