Déjà Dup is really just a clever graphical wrapper around the command line backup tool duplicity. You can read more about it on its homepage, but basically, it uses rsync to generate incremental, encrypted backup volumes.


Déjà Dup does not use cron or similar schedulers. Rather, it starts a program deja-dup-monitor when you log into your session. This keeps track of when you last successfully backed up and will wait until the next scheduled backup.

It determines exactly when the next scheduled backup is largely on its own, based on the user's preferences about whether to backup once a day, once a week, etc. There is no way to currently specify "as close to 4AM on Thursday as possible". See bug 479191 for the related feature request.

Why Not Cron?

A monitoring program is used because access to the user session is useful for:

  • prompting for passwords
  • displaying status in the panel
  • watching for events like plugging in a remote disk or becoming connected to the Internet

One disadvantage is that a backup can not be started while a user is not logged in. The primary use case for Déjà Dup is backing up user data, so this is not a large concern, as user data is unlikely to change while the user are not logged in.


Déjà Dup relies on duplicity to handle the encryption, and it uses gpg with a symmetric cipher. Basically, that means it is encrypted just with the password your provide. You will need to remember that password to restore your data.

If you choose to have Déjà Dup remember your password, it will be stored in the default GNOME keyring.

Backup File Format

Déjà Dup uses an opaque format for files stored in your backup location. You must use Déjà Dup or another duplicity-based tool to restore your files. This is opposed to a native format where you can browse and examine your files using any normal file tool.

This naturally is a bummer. But it is necessary to support Déjà Dup's feature set:

  • Encryption
  • Compression
  • Incremental backups
  • Assuming little about location (allowing cloud backups)
  • Supporting file permissions, even when backing up to locations that don't

Because of all the above, it is impossible to allow a version of your files that is accessible without duplicity. Note that there is a way to get your data back by hand, but it's not fun or easy.

Full Backups

Déjà Dup will occasionally make fresh full backups for you. This takes up more space and more time, but offers the following benefits:

  • Sometimes there are bugs. If a bug appeared in the middle of a chain of a year of incremental backups, you would lose 6 months of backups. Now, bugs aren't expected, but better safe than sorry. The occasional full backup prevents hideously long chains of incremental backups, which can be risky.
  • Full backups allow Déjà Dup to delete old backups. If it didn't create a new full checkpoint, it could never delete old full checkpoints and their chains of incremental backups.

Déjà Dup assumes that disk space is cheap, that time-to-backup isn't a terribly important detail, and that safety of data is paramount.

Deleting Old Backups

Déjà Dup lets you specify that you want backups to be kept for a period of time (say, a month), after which, you are OK with the backups being deleted. This does not mean that immediately after a month, Déjà Dup will delete all older backups. It's more complicated than that:

  • Déjà Dup can only delete a complete chain of backups at a time. That is, a full backup and all its associated incremental backups.
  • Déjà Dup still wants to keep two full backups around at all times (see above).
  • There is a balance between making too many full backups (wasted time and space) and too few (backup chains become very long).

Assume that you have Déjà Dup setup to make a weekly backup and keep backups at least a month. As of this writing, that means that Déjà Dup will make a new full backup every month. So, let's say you start January 1st:

  1. Jan 1st: Full Backup A
  2. Jan 8th: Incremental Backup A1
  3. Jan 15th: Incremental Backup A2
  4. Jan 22nd: Incremental Backup A3
  5. Jan 29th: Incremental Backup A4
  6. Feb 5th: Full Backup B (Won't delete backup chain A because we always keep two full backups)

  7. Feb 12th: Incremental Backup B1
  8. Feb 19th: Incremental Backup B2
  9. Feb 26th: Incremental Backup B3
  10. Mar 5th: Incremental Backup B4
  11. Mar 12th: Full Backup C (After this, the last incremental backup in chain A is over a month old and we have two full backups, so chain A will be deleted)

Apps/DejaDup/HowItWorks (last edited 2019-01-13 04:25:12 by MichaelTerry)