On a fresh Ubuntu 18.04 system I decided to give Deja-Dup a go. It's just a GUI for Duplicity (which uses rsync). About 850GB of data needed to be backed up. Source SSD was NVMe. Destination SSD was SATA. Initial (full) backup took about 7 hours.

The next day I did nothing more than check mail and install an application — which added ~230MB — before running Deja-Dup again.

Deja-Dup ran for ~39 minutes loading a single core at 35–70% for the entire duration.

Duplicity was invoked three times:

  • The Scanning phase pegged a core at 100% for 18 minutes.
  • The Backing Up phase pegged a core at 100% for 16 minutes.
  • The Verifying phase pegged a core at 100% for 5 minutes.

This is on a new computer with plenty of RAM. The backup was not encrypted.

Now, I expect initial (full) backups to take a while, and that's fine. What I don't expect is for ~230MB of new data to take ~39 minutes to be backed up (and consume over a collective core-hour of CPU time).

Is something wrong or broken? Should incremental backups of a couple of hundred megabytes take that much time to perform? I was expecting something under 5 minutes, not ~39. Why is it taking so long?

(If I had a spare 1TB SATA SSD I'd hook it up and just rsync the data straight across to see if that is noticeably faster — but unfortunately I do not.)

Update 1: I ran a manual backup after negligible changes (a few KB of new mail) and the time taken was the same (~39 minutes). Thus the time taken seems to have little to do with the amount of new data that needs to be backed up.

Update 2: Monitoring with iotop revealed that the Scanning phase reads 7.36GB from the drive. Now that's obviously not the whole 850GB... but it's not far removed from the number you get if you multiply the number of files on the source drive (1174000) by the block/cluster size (4096) — i.e. 4.81GB. Not sure how to account for the remaining 2.5GB though, if this were the case.

  • Perhaps it made a 2nd full backup? I've never used the gui. Try looking iin the backup directory to see what new files it created. I think you should see files ` duplicity-inc.*` for the incremental backup.
    – meuh
    Apr 29, 2018 at 8:33
  • Yep, I've got the duplicity.inc files for today and they seem to be about the right size (~15% compression). The rest is dated yesterday. The destination SSD is only 1TB so it couldn't fit two full backups without overwriting (parts of) the first anyway. So it looks like the programs did the job correctly. I'm just concerned about how long it took them to do it.
    – Tim
    Apr 29, 2018 at 8:49
  • 1
    I'm not sure how duplicity works when doing a comparison. Whereas rsync typically is configured to just compare timestamps and sizes, I think duplicity recomputes a "signature" for each file, which involves reading the whole file and comparing it with the saved signature in the backup. If so, the scan/backup is having to read all 850Gby of your disk to collect the signatures.
    – meuh
    Apr 29, 2018 at 9:14
  • If that's the case, then won't the atime on every file be modified and, because they're on SSD, won't that then trigger the rewriting of all 850GB in the process? (Or at least the first inode of each file, of which there's ~1.1 million?)
    – Tim
    Apr 29, 2018 at 20:02
  • Linux has optimised atime, see man 8 mount for relatime etc. Also, some backup programs will explicitly call utimes() to restore the atime after reading the file. I don't know what duplicity does.
    – meuh
    Apr 29, 2018 at 20:38

1 Answer 1


I can confirm that the Deja-Dup/Duplicity combination just makes the backing up process atrociously slow (~156x slower, in fact).

I ended up wiping the Deja-Dup/Duplicity backup and just went with pure rsync. Backups are now taking as little as 15 seconds.

$ rsync -a --delete /home/tim /media/tim/BackupDrive/

Unless you really, really, really need the simplicity that Deja-Dup provides or the features that Duplicity provides then don't even bother — you're just wasting CPU cycles, time, electricity, causing unnecessary wear on your drive, and you end up with a fragile backup. Deja-Dup/Duplicity is a horribly inefficient way to simply back up files from one local drive to another.

For simple, automated, unencrypted, local backups all you need is to add a rsync entry to your crontab.

  • How much encryption does rsync add?
    – MPi
    Nov 21, 2019 at 7:42
  • To the best of my knowledge, the standard rsync is not capable of encryption. So... zero?
    – Tim
    Nov 21, 2019 at 12:54
  • Déjà dup, however, encrypts the backup. I have no idea what the reference to librsync in the docs means, but it’s certainly not just rsync. So, I use it not for its simplicity – well, not only – but also for its encryption. I don’t thinkt it’s only a waste of CPU cycles.
    – MPi
    Nov 21, 2019 at 20:20
  • If encryption is a wanted/needed feature then you are right, rsync by itself won't be sufficient. I didn't investigate how much additional time would be required to encrypt the backups because a simple file copy was all I needed. I'll update my answer to make that clearer.
    – Tim
    Nov 21, 2019 at 22:29
  • 1
    I've been using rsync to backup my data to another machine over ssh and decided to give deja-dup a try and can confirm it feels slower (uses duplicity under the hood). App also needs to be improved: asks for external disk password, if I get it wrong it doesn't ask again; when backup is being made there is no feedback to the user of progress; had Trash in my ignore list and deja-dup still wanted to back it up;etc. I think it's a great idea to have a simple tool for less tech-savvy users but it still needs work.
    – Daniel
    Dec 3, 2020 at 16:23

You must log in to answer this question.

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