Backup fails with 'Error: No data available'

[Michael Rodríguez-Torrent]

When attempting to run a backup of my home directory to a network mount, Deja Dup eventually reports that the backup has failed with "Error: Invalid argument."

I'm running Ubuntu 9.10

I have tried this on both the current stable release (11.1) and the current edge release (13.92).

Duplicity version is 0.6.08-0ubuntu0karmic1

gconf is attached

The end of the debug log follows:

DUPLICITY: INFO 2 90202160095

DUPLICITY: WARNING 10 '/lost+found'
DUPLICITY: . Error accessing possibly locked file /lost+found

DUPLICITY: WARNING 10 '/root'
DUPLICITY: . Error accessing possibly locked file /root

DUPLICITY: INFO 2 90202160095

DUPLICITY: DEBUG 1
DUPLICITY: . Removing still remembered temporary file /tmp/duplicity-CVEgG8-tempdir/mkstemp-J9KUEY-1

DUPLICITY: ERROR 30 Error
DUPLICITY: . Traceback (most recent call last):
DUPLICITY: . File "/usr/bin/duplicity", line 1239, in <module>
DUPLICITY: . with_tempdir(main)
DUPLICITY: . File "/usr/bin/duplicity", line 1232, in with_tempdir
DUPLICITY: . fn()
DUPLICITY: . File "/usr/bin/duplicity", line 1210, in main
DUPLICITY: . full_backup(col_stats)
DUPLICITY: . File "/usr/bin/duplicity", line 408, in full_backup
DUPLICITY: . col_stats.set_values(sig_chain_warning=None)
DUPLICITY: . File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658, in set_values
DUPLICITY: . backend_filename_list = self.backend.list()
DUPLICITY: . File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 127, in list
DUPLICITY: . gio.FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)
DUPLICITY: . Error: Invalid argument

[Michael Rodríguez-Torrent (mrtorrent)]

Attempting to run the same backup in 14.01 results in the same trace and a slightly different error message:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1239, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1232, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1210, in main
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 408, in full_backup
    col_stats.set_values(sig_chain_warning=None)
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658, in set_values
    backend_filename_list = self.backend.list()
  File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 127, in list
    gio.FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)
Error: No data available

[Michael Rodríguez-Torrent (mrtorrent)]

Hi, is there any chance of some assistance in sorting this? It makes Deja Dup completely unusable (i.e. it does not perform its primary function -- back stuff up).

Trace and error in 14.1 remain the same:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1239, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1232, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1210, in main
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 408, in full_backup
    col_stats.set_values(sig_chain_warning=None)
  File "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658, in set_values
    backend_filename_list = self.backend.list()
  File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 127, in list
    gio.FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)
Error: No data available

Thanks!

[Michael Terry (mterry)]

Sorry for late responses. My best guess is that it has to do with backing up over samba. I am not able to test against my samba machine right now, but you're the first report I've seen of this (though samba has proven difficult in the past too).

My best advice right now is to backup locally or somewhere else. I will test here against samba when I can (not for a week).

I'm not sure how to get more information out of gvfsd. Does dbus-monitor show anything interesting when the error occurs? (you will get lots of non-backup related spew from dbus-monitor)

[Luis Villa (luis-villa)]

For what it is worth, I'm seeing the same error message, also to a samba backup target, using 14.1 on Fedora 13. Let me know if you'd like me to get any debug logs, etc.

[Serge Stroobandt (serge-stroobandt)]

I have a very similar problem but than with a regular ext3 mount as target,
see my duplicity bug report at:

https://bugs.launchpad.net/duplicity/+bug/610603

[Michael Rodríguez-Torrent (mrtorrent)]

Hi, and sorry for the much delayed response. This is still something I'm desperate to get working, as none of the other Linux-based solutions fit into my workflow as well.

I've done a bit more testing today, including running dbus-monitor. I've attached the output, but it doesn't look like anything interesting.

Perhaps more importantly, however, I've tested backing up smaller sets of my files successfully. This is still to the same SMB mount, so it starts to look like Samba is not the issue, what do you think? Anything else I can do to help track this down?

[Michael Rodríguez-Torrent (mrtorrent)]

Here are the last 200 lines of my Deja Dup debug log (the full file is 1.1GB). As you can see, the last lines before the error are the same as in previous attempts. For some reason it's trying to access /lost+found and /root, even though I am only backing up my home directory.

My current version of Deja Dup is now 14.2-0ubuntu0karmic2

[Michael Rodríguez-Torrent (mrtorrent)]

Hi again, still hoping to get a response out of this, as it continues to occur in 16.1.1 for Maverick. I realise Natty's out, with a new Deja Dup version, but I'd really like to have a backup in hand before I run the update. :)

Several months ago, I somehow managed to get a backup to complete by first selectively backing up directories in my home dir to see if any failed. One did, and excluding this resulted in an apparently successful backup of my whole home dir. It's only worked the once, though, and is now failing again.

[Michael Terry (mterry)]

Heyo, sorry for lack of response. So it looks like the original "Invalid argument" hasn't been since in forever. Just the "No data available" error.

This is back on my radar.

[Michael Terry (mterry)]

So, the error is happening when we try to list the files in the backup directory after scanning local files to see what we would upload (according to your log).

I'm guessing some interaction here between gvfs and samba is at fault. Searching the net has not been particularly fruitful. Some people report similar errors, but not many, and no reproduction steps.

https://bugs.kde.org/show_bug.cgi?id=156549
http://ubuntuforums.org/showthread.php?t=1761348

What's your NAS like (model, samba version)? I'm curious if you and Luis have the same versions.

Does the NAS have available firmware upgrades? (I ask, because that KDE bug was solved by a firmware upgrade.)

[Michael Rodríguez-Torrent (mrtorrent)]

Hi Michael, I've been doing some more experimentation yesterday and today and I have a theory of sorts. First of all, I've seen a couple of different error messages on various attempts:

ERROR 50 list 'smb://du-nas1/share/backup_miquel'
. No data available

This one seems to be the same as the previous errors but with more detail, showing, as you say, that it's trying to access the backup directory.

Backup location ‘/smb:/du-nas1/share/backup_miquel/duplicity-full.20110526T182540Z.manifest.part’ does not exist.

I received this error on another attempt. Could this be due to a truncated earlier backup? Interestingly, although the Deja Dup UI gave the impression that the backup had completely failed (showing only this error message and a "close" button), duplicity was still running and, based on the console output, continuing to write the backup to the NAS. It carried on like this for at least a few hours. Unfortunately I'm not sure whether it fully completed or not, because the last time I returned to check on it my computer had become unresponsive and I had to do a hard reset. The last line in the log file is just another "DUPLICITY: . Writing" line. It was on volume 1674. Would it say if it had finished?

So, my theory. I'm attempting to back up my home directory, which is fairly sizeable (?GB). It takes Deja Dup/duplicity quite a while to scan the whole thing -- perhaps an hour or two -- and I suspect that, in this time, they never hit the NAS. I've noticed that, like the Ubuntu Forums user, if I come back after a while and open up or refresh the SMB share in Nautilus, it also gives the "No data" message, but then seems to reconnect. Maybe the connection times out after a period of inactivity so that, by the time DD/duplicity is done scanning, the connection has dropped.

I tested this theory on my last backup attempt by returning to the computer periodically and opening the SMB share in Nautilus. Except for the error above about the manifest, this seems to have worked. When I took a successful backup a few months ago, I thought that it ruled out Samba issues, but it's entirely possible that I had similarly kept checking the share and, in so doing, unwittingly kept the connection from timing out.

To answer your questions about the NAS, it's a Buffalo Linkstation Pro LS-XHL 1TB. Unfortunately, there's no way that I know of to determine the Samba version in the stock firmware. There is an update available, but frustratingly it can only be applied via a Windows flasher and my attempts to run it both under Wine and in a virtualized environment have all failed. The changelog doesn't speak of any updates to Samba, however.

Now that I've had a few botched backup attempts, is this going to muck up future incremental backups? Is there any way to verify the integrity of a whole backup? Should I just delete all artifacts and start over?

[Michael Rodríguez-Torrent (mrtorrent)]

Oops, I wrote (?GB) as the size of my home directory. I was waiting for the results of du, but considering it's been half an hour already, I've given up!

[Michael Terry (mterry)]

> Backup location ‘/smb:/du-nas1/share/backup_miquel/duplicity-full.20110526T182540Z.manifest.part’ does not exist.

Odd error. See the leading slash and only one slash after the colon? Looks like some piece of code tried to normalize a URL into a full path. Also odd that DD treated this message as a fatal error, but Duplicity didn't. Can I see some of the verbose log output around this error?

> Would it say if it had finished?

Yes. Duplicity spits out a bunch of finishing-up output.

> Now that I've had a few botched backup attempts, is this going to muck up future incremental backups?

No, should be fine. In theory, duplicity can resume from aborted attempts no problem.

> Is there any way to verify the integrity of a whole backup?

Duplicity has a 'verify' command, but that doesn't guarantee that it is fully restorable. Best way to test that is to do a restore. There are open feature requests for DD to make it easier to verify a backup, but it isn't coded yet.

> Should I just delete all artifacts and start over?

Wouldn't hurt. Could just move them to a different directory or point DD at a different directory rather than delete them. There shouldn't be a need though.

> Maybe the connection times out after a period of inactivity so that, by the time DD/duplicity is done scanning, the connection has dropped.

I like this theory. Duplicity has code to retry writes/reads of files up to (by default) 5 times. But it currently doesn't use that logic for list or delete operations. I'm going to whip up a version of duplicity that does and post it to this bug. Hopefully you can then try it for me.

Thanks for all your help so far!

[Michael Terry (mterry)]

Here, can you please put this in /usr/share/pyshared/duplicity/backends and try again?

[Michael Rodríguez-Torrent (mrtorrent)]

Re: the new error message, here are lines 15335245-15335845 of the output. You can see the error occur on line 60 of this file.

I'm giving the new giobackend a try just now; will let you know how it's gone in a few hours.

[Michael Rodríguez-Torrent (mrtorrent)]

My system froze again the next time I tried to do a backup, so I've been running diagnostics for the past 36 hours. Think it might be an eCryptFS bug which they haven't yet released a fix for in Maverick. At any rate, it means that I haven't been able to see a backup job all the way through yet.

The good news is that I tried again with full logging last night and, although the system froze a few hours in as usual, the last Deja Dup output shows that it was continuing to write to the NAS all the way until the end. It got all the way to vol4356 this time!

So I think that bodes well for your fix. I'm going to keep hammering away at the system hang issue and, if I get anywhere, run a full backup tonight and let you know how that goes.

[Michael Rodríguez-Torrent (mrtorrent)]

I've run a few more backups which have gotten a bit further. The first one displayed the "backup location does not exist" error again, even though I'd emptied the target directory in order to get a fresh, full backup. As before, duplicity continued in the background and got to volume 9800 or so before my computer locked up.

Next, I cleared out about around 25 gigs of cruft in the hopes of getting through backups faster, leaving me with about 225 GB to back up. The following attempt got to volume 8931 but resulted in a brand new error:

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1262, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1255, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1228, in main
    full_backup(col_stats)
  File "/usr/bin/duplicity", line 417, in full_backup
    globals.backend)
  File "/usr/bin/duplicity", line 316, in write_multivol
    (tdp, dest_filename)))
  File "/usr/lib/python2.6/dist-packages/duplicity/asyncscheduler.py", line 145, in schedule_task
    return self.__run_synchronously(fn, params)
  File "/usr/lib/python2.6/dist-packages/duplicity/asyncscheduler.py", line 171, in __run_synchronously
    ret = fn(*params)
  File "/usr/bin/duplicity", line 315, in <lambda>
    async_waiters.append(io_scheduler.schedule_task(lambda tdp, dest_filename: put(tdp, dest_filename),
  File "/usr/bin/duplicity", line 241, in put
    backend.put(tdp, dest_filename)
  File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 141, in put
    self.copy_file('put', source_file, target_file)
  File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 70, in iterate
    return fn(*args, raise_errors=False)
  File "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line 126, in copy_file
    % (target.get_parse_name(), n, e.__class__.__name__, str(e)))
NameError: global name 'n' is not defined

Attached are 500 lines of context

[Michael Rodríguez-Torrent (mrtorrent)]

Had a look at giobackend.py, and I guess the error came up because the exception handler expects the iterator counter n to be in scope, but it's not. The bigger problem, however, is that the exception occurred -- which I suppose has to mean that the write failed multiple times.

Any idea why it would at this point? The backup had been running for somewhere approaching 18 hours by then without problem. Is the retry cumulative across the entire execution or is it per write?

[Kenneth Loafman (kenneth-loafman)]

I'll look into this over the weekend.

The error counter is per write, not overall. There really should be an
overall error count just to document how many errors occurred.

On Sat, Jun 11, 2011 at 10:26 AM, Michael Rodríguez-Torrent <
<email address hidden>> wrote:

> Had a look at giobackend.py, and I guess the error came up because the
> exception handler expects the iterator counter n to be in scope, but
> it's not. The bigger problem, however, is that the exception occurred --
> which I suppose has to mean that the write failed multiple times.
>
> Any idea why it would at this point? The backup had been running for
> somewhere approaching 18 hours by then without problem. Is the retry
> cumulative across the entire execution or is it per write?
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/545486
>
> Title:
> Backup fails with 'Error: No data available'
>
> Status in Déjà Dup Backup Tool:
> In Progress
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> When attempting to run a backup of my home directory to a network
> mount, Deja Dup eventually reports that the backup has failed with
> "Error: Invalid argument."
>
> I'm running Ubuntu 9.10
>
> I have tried this on both the current stable release (11.1) and the
> current edge release (13.92).
>
> Duplicity version is 0.6.08-0ubuntu0karmic1
>
> gconf is attached
>
> The end of the debug log follows:
>
> DUPLICITY: INFO 2 90202160095
>
> DUPLICITY: WARNING 10 '/lost+found'
> DUPLICITY: . Error accessing possibly locked file /lost+found
>
> DUPLICITY: WARNING 10 '/root'
> DUPLICITY: . Error accessing possibly locked file /root
>
> DUPLICITY: INFO 2 90202160095
>
> DUPLICITY: DEBUG 1
> DUPLICITY: . Removing still remembered temporary file
> /tmp/duplicity-CVEgG8-tempdir/mkstemp-J9KUEY-1
>
> DUPLICITY: ERROR 30 Error
> DUPLICITY: . Traceback (most recent call last):
> DUPLICITY: . File "/usr/bin/duplicity", line 1239, in <module>
> DUPLICITY: . with_tempdir(main)
> DUPLICITY: . File "/usr/bin/duplicity", line 1232, in with_tempdir
> DUPLICITY: . fn()
> DUPLICITY: . File "/usr/bin/duplicity", line 1210, in main
> DUPLICITY: . full_backup(col_stats)
> DUPLICITY: . File "/usr/bin/duplicity", line 408, in full_backup
> DUPLICITY: . col_stats.set_values(sig_chain_warning=None)
> DUPLICITY: . File
> "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658, in
> set_values
> DUPLICITY: . backend_filename_list = self.backend.list()
> DUPLICITY: . File
> "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line
> 127, in list
> DUPLICITY: . gio.FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)
> DUPLICITY: . Error: Invalid argument
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/deja-dup/+bug/545486/+subscriptions
>

[Kenneth Loafman (kenneth-loafman)]

Have you tried the latest version, 0.6.13? Some of the problems you are
encountering are fixed in that version.

...Ken

On Sat, Jun 11, 2011 at 10:54 AM, Kenneth Loafman <email address hidden>wrote:

> I'll look into this over the weekend.
>
> The error counter is per write, not overall. There really should be an
> overall error count just to document how many errors occurred.
>
>
> On Sat, Jun 11, 2011 at 10:26 AM, Michael Rodríguez-Torrent <
> <email address hidden>> wrote:
>
>> Had a look at giobackend.py, and I guess the error came up because the
>> exception handler expects the iterator counter n to be in scope, but
>> it's not. The bigger problem, however, is that the exception occurred --
>> which I suppose has to mean that the write failed multiple times.
>>
>> Any idea why it would at this point? The backup had been running for
>> somewhere approaching 18 hours by then without problem. Is the retry
>> cumulative across the entire execution or is it per write?
>>
>> --
>> You received this bug notification because you are subscribed to
>> Duplicity.
>> https://bugs.launchpad.net/bugs/545486
>>
>> Title:
>> Backup fails with 'Error: No data available'
>>
>> Status in Déjà Dup Backup Tool:
>> In Progress
>> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
>> New
>>
>> Bug description:
>> When attempting to run a backup of my home directory to a network
>> mount, Deja Dup eventually reports that the backup has failed with
>> "Error: Invalid argument."
>>
>> I'm running Ubuntu 9.10
>>
>> I have tried this on both the current stable release (11.1) and the
>> current edge release (13.92).
>>
>> Duplicity version is 0.6.08-0ubuntu0karmic1
>>
>> gconf is attached
>>
>> The end of the debug log follows:
>>
>> DUPLICITY: INFO 2 90202160095
>>
>> DUPLICITY: WARNING 10 '/lost+found'
>> DUPLICITY: . Error accessing possibly locked file /lost+found
>>
>> DUPLICITY: WARNING 10 '/root'
>> DUPLICITY: . Error accessing possibly locked file /root
>>
>> DUPLICITY: INFO 2 90202160095
>>
>> DUPLICITY: DEBUG 1
>> DUPLICITY: . Removing still remembered temporary file
>> /tmp/duplicity-CVEgG8-tempdir/mkstemp-J9KUEY-1
>>
>> DUPLICITY: ERROR 30 Error
>> DUPLICITY: . Traceback (most recent call last):
>> DUPLICITY: . File "/usr/bin/duplicity", line 1239, in <module>
>> DUPLICITY: . with_tempdir(main)
>> DUPLICITY: . File "/usr/bin/duplicity", line 1232, in with_tempdir
>> DUPLICITY: . fn()
>> DUPLICITY: . File "/usr/bin/duplicity", line 1210, in main
>> DUPLICITY: . full_backup(col_stats)
>> DUPLICITY: . File "/usr/bin/duplicity", line 408, in full_backup
>> DUPLICITY: . col_stats.set_values(sig_chain_warning=None)
>> DUPLICITY: . File
>> "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658, in
>> set_values
>> DUPLICITY: . backend_filename_list = self.backend.list()
>> DUPLICITY: . File
>> "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py", line
>> 127, in list
>> DUPLICITY: . gio.FILE_QUERY_INFO_NOFOLLOW_SYMLINKS)
>> DUPLICITY: . Error: Invalid argument
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/deja-du...

[Michael Rodríguez-Torrent (mrtorrent)]

Hi Ken, 0.6.13 is already the version I'm running.
On 12 Jun 2011 17:00, "Kenneth Loafman" <email address hidden> wrote:
> Have you tried the latest version, 0.6.13? Some of the problems you are
> encountering are fixed in that version.
>
> ...Ken
>
> On Sat, Jun 11, 2011 at 10:54 AM, Kenneth Loafman
> <email address hidden>wrote:
>
>> I'll look into this over the weekend.
>>
>> The error counter is per write, not overall. There really should be an
>> overall error count just to document how many errors occurred.
>>
>>
>> On Sat, Jun 11, 2011 at 10:26 AM, Michael Rodríguez-Torrent <
>> <email address hidden>> wrote:
>>
>>> Had a look at giobackend.py, and I guess the error came up because the
>>> exception handler expects the iterator counter n to be in scope, but
>>> it's not. The bigger problem, however, is that the exception occurred --
>>> which I suppose has to mean that the write failed multiple times.
>>>
>>> Any idea why it would at this point? The backup had been running for
>>> somewhere approaching 18 hours by then without problem. Is the retry
>>> cumulative across the entire execution or is it per write?
>>>
>>> --
>>> You received this bug notification because you are subscribed to
>>> Duplicity.
>>> https://bugs.launchpad.net/bugs/545486
>>>
>>> Title:
>>> Backup fails with 'Error: No data available'
>>>
>>> Status in Déjà Dup Backup Tool:
>>> In Progress
>>> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
>>> New
>>>
>>> Bug description:
>>> When attempting to run a backup of my home directory to a network
>>> mount, Deja Dup eventually reports that the backup has failed with
>>> "Error: Invalid argument."
>>>
>>> I'm running Ubuntu 9.10
>>>
>>> I have tried this on both the current stable release (11.1) and the
>>> current edge release (13.92).
>>>
>>> Duplicity version is 0.6.08-0ubuntu0karmic1
>>>
>>> gconf is attached
>>>
>>> The end of the debug log follows:
>>>
>>> DUPLICITY: INFO 2 90202160095
>>>
>>> DUPLICITY: WARNING 10 '/lost+found'
>>> DUPLICITY: . Error accessing possibly locked file /lost+found
>>>
>>> DUPLICITY: WARNING 10 '/root'
>>> DUPLICITY: . Error accessing possibly locked file /root
>>>
>>> DUPLICITY: INFO 2 90202160095
>>>
>>> DUPLICITY: DEBUG 1
>>> DUPLICITY: . Removing still remembered temporary file
>>> /tmp/duplicity-CVEgG8-tempdir/mkstemp-J9KUEY-1
>>>
>>> DUPLICITY: ERROR 30 Error
>>> DUPLICITY: . Traceback (most recent call last):
>>> DUPLICITY: . File "/usr/bin/duplicity", line 1239, in <module>
>>> DUPLICITY: . with_tempdir(main)
>>> DUPLICITY: . File "/usr/bin/duplicity", line 1232, in with_tempdir
>>> DUPLICITY: . fn()
>>> DUPLICITY: . File "/usr/bin/duplicity", line 1210, in main
>>> DUPLICITY: . full_backup(col_stats)
>>> DUPLICITY: . File "/usr/bin/duplicity", line 408, in full_backup
>>> DUPLICITY: . col_stats.set_values(sig_chain_warning=None)
>>> DUPLICITY: . File
>>> "/usr/lib/python2.6/dist-packages/duplicity/collections.py", line 658,
in
>>> set_values
>>> DUPLICITY: . backend_filename_list = self.backend.list()
>>> DUPLICITY: . File
>>> "/usr/lib/python2.6/dist-packages/duplicity/backends/giobackend.py",
line
>>> 127, in list
>>> DUPLICITY: . gio.FILE_QUERY_INFO_NOFOLLOW_...

[Michael Terry (mterry)]

I fixed the use of the 'n' variable in my proposed 'retry-decorator' merge branch. In the copy of the file you have, Michael, you could just replace the variable 'n' with a string like 'hello' just so it doesn't worry about it and you can see the real error.

[Michael Rodríguez-Torrent (mrtorrent)]

Yeah, I removed it and the reference to it in the formatted string and tried again. And now -- 23.5 hours later -- miracle of miracles -- wonder of wonders -- the backup is complete! Da-da! The error didn't trigger this time, but I'm so deliriously happy I couldn't care less why that is!

In all seriousness, though, the last failure could have just been a fluke, such as a network issue. Frustrating in a massive backup set like this, but I suppose for regularly scheduled backups it would just be retried and resumed during the next backup, is that right?

I guess the next thing to do will be to try a restore to a temporary directory to see whether that works.

One thing I think I noticed in retrying these backups was that in order to avoid triggering the "backup location ... does not exist" error, I couldn't just delete the contents of the backup target directory but had to actually use a directory with a different name. I noticed that the reporter in https://bugs.launchpad.net/deja-dup/+bug/779022 received the same error, also after deleting the contents of the target directory. Would you like me to file a separate bug for this?

[Michael Terry (mterry)]

Based on that report of success, I'll tentatively mark this fix committed in Duplicity (my patch landed in trunk today).

> but I suppose for regularly scheduled backups it would just be retried and resumed during the next backup, is that right?

Yes, true.

> Would you like me to file a separate bug for this?

Yes, please, thanks. I probably have to watch for that message and clear out the cache too in order to fix it.

[Michael Rodríguez-Torrent (mrtorrent)]

Just wanted to report that a couple of daily scheduled backups have run without any interaction from me. I believe they were successful, as no errors were reported. The SMB share from my NAS was mounted automatically as the backup ran, whereas in the past I believe I had to first mount it myself through Nautilus.

Thanks very much for sorting this, it's a relief to have backups running again.