No relevant progress info while doing the actual backup in Dejadup

[markba]

When doing the actual backup, the progress bar is moving from 0 to 100% without any intermediate steps. What also good be usefull: an indication what het upload speed is, and in conjunction with the file size, a calculated ETA.

To have some user feedback, is especially important when backing up to cloudbased targets like SSH or U1, because they are limited by a relatively small upload bandwidth. As for now, the upload seems broken, because a user cannot see any progress, only when it's ready.

[Michael Terry (mterry)]

I'm not seeing this. Can you provide the following information? Also, do you happen to know if these backups are full or incremental ones?

1. The version of deja-dup and duplicity:
    dpkg-query -W deja-dup duplicity

2. The file /tmp/deja-dup.gsettings after running the following line (you may want to scrub the file of any incriminating file names or details):
    gsettings list-recursively org.gnome.DejaDup > /tmp/deja-dup.gsettings

3. The file /tmp/deja-dup.log after running the appropriate line below and replicating the problem (you may want to scrub the log of any incriminating file names or details):
    DEJA_DUP_DEBUG=1 deja-dup --backup | tail -n 1000 > /tmp/deja-dup.log

[markba (mark-baaijens)]

> Also, do you happen to know if these backups are full or incremental ones?
In my situation, it does not make a change whether it's a full or incremental backup: as soon as the upload begins, it starts with 0 (that's logical) en jumps to 100 when ready, no step between.

On the plus side: when doing a restore-action, (download) progress is shown per file, so that's good.

>1. The version of deja-dup and duplicity:
> dpkg-query -W deja-dup duplicity
deja-dup 19.92-0ubuntu1
duplicity 0.6.15-0ubuntu2

>2. The file /tmp/deja-dup.gsettings after running the following line (you may want to scrub the file of any incriminating file >names or details):
> gsettings list-recursively org.gnome.DejaDup > /tmp/deja-dup.gsettings
org.gnome.DejaDup backend 'u1'
org.gnome.DejaDup delete-after 0
org.gnome.DejaDup exclude-list ['$TRASH', '$DOWNLOAD']
org.gnome.DejaDup include-list ['/home/user/Temp']
org.gnome.DejaDup last-backup '2011-09-18T07:11:33.662436Z'
org.gnome.DejaDup last-restore '2011-09-18T07:15:29.661215Z'
org.gnome.DejaDup last-run '2011-09-18T07:15:29.661215Z'
org.gnome.DejaDup periodic false
org.gnome.DejaDup periodic-period 7
org.gnome.DejaDup prompt-check '2011-09-03T21:42:06.499803Z'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup welcomed true
org.gnome.DejaDup.File icon ''
org.gnome.DejaDup.File name ''
org.gnome.DejaDup.File path 'sftp://eco@192.168.0.210/home/eco/deja-dup'
org.gnome.DejaDup.File relpath @ay []
org.gnome.DejaDup.File short-name ''
org.gnome.DejaDup.File type 'normal'
org.gnome.DejaDup.File uuid ''
org.gnome.DejaDup.Rackspace container 'asus-mark'
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder 'asus-mark'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.U1 folder 'deja-dup/asus-mark'

> 3. The file /tmp/deja-dup.log after running the appropriate line below and replicating the problem (you may want to scrub the > log of any incriminating file names or details):
> DEJA_DUP_DEBUG=1 deja-dup --backup | tail -n 1000 > /tmp/deja-dup.log
See attachment.

[Michael Terry (mterry)]

Thanks! From your log, it looks like things are working just fine. You only have ~/Temp being backed up, and that directory doesn't seem to be changing much.

So each backup, Deja Dup is doing an incremental backup of only the changes. It takes a while to calculate what it needs to back up (that's it sitting at 0% for a while). Then, it realizes there's almost nothing, quickly makes a volume file saying so, and uploads it. Which doesn't take long, so it quickly moves to 100%.

[markba (mark-baaijens)]

I've retested with both full backup (by removing all existing dejadup-files) and incremental baclups (by adding sourcecode from a site with a huge number of small *and* big files) and the result stays the same: the progress bar bumps from 0 to 100% every time.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[shankao (shankao)]

Deja-dup seems to calculate the completion percentage based on the current status versus the total number of files to backup, instead of versus the full backup size (based on my personal observations).
So, if there's just one big file and some small ones, it will jump from 0% to 100% (or 99% for a moment, while backing up the small ones) without any intermediate value.

[Michael Terry (mterry)]

The latest duplicity release added a new progress bar built in to its backup operation. I haven't looked at integrating that yet, but it would potentially help with this.