Simple backup tool for GNOME
Read our Mission Statement for full details, but basically we aim to convert people who don't currently have backups into people that do.
This may mean that we are too simple for some use cases. That's fine. We don't need to solve all backup needs.
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 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, six months), after which, you are OK with the backups being deleted. This does not mean that immediately after six months, 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 six months. By default, Déjà Dup will make a new full backup every three months. So, let's say you start January 1st:
- Jan 1st: Full Backup A
- Jan 8th: Incremental Backup A1
Apr 1st: Full Backup B (Won't delete backup chain A yet because we always keep two full backups)
- Apr 8th: Incremental Backup B1
Jul 1st: Full Backup C (Won't delete backup chain A yet because its oldest incremental backup is less than six months old and we can only delete a full chain at once)
- Jul 8th: Incremental Backup C1
Sep 30th: Incremental Backup C13 (After this, the last incremental backup in chain A is over six months old and we have more than two full backups, so chain A will be deleted)
(Those dates are a little fuzzy, since Déjà Dup actually works off days rather than months internally and its weekly backups wouldn't all fall on the 1st of each month anyway. But I'm just using the 1st of each month to make the logic easier to follow.)
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:
- 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.
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 issue 111 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 follows the GNOME versioning scheme, but without following the GNOME release schedule.
Déjà Dup releases are not time based. Rather, the major number is incremented when a new release subjectively adds big enough features or changes features or dependencies in an important way.
For example, release 42.6 might be followed by a 43.alpha and/or 43.0 if Déjà Dup got ported from GTK 3 to GTK 4.
What's With the Name?
Déjà Dup is pronounced like day-ja-doop. It's a play on the French phrase "déjà vu" and "dup" from "duplication".
Once installed, it may show up as simply "Backups" in menus, app launchers, and some in-app text. This is to appear more tightly integrated into the system and to avoid confusion around the odd name.
But in app stores and formal contexts, we prefer the unambiguous "Déjà Dup Backups" to distinguish between multiple backup apps.
We aim to only focus on consumer-friendly cloud services. The full policy has more details, including which cloud services are deprecated.