Cannot recover from upload failure

A long upload was moving along nicely, but failed last night. It just stopped with no messages. I tried starting it again, but received a message that a sqlite log table was missing. Tried db repair, which failed. Tried db delete/recreate, and that failed, too.

Here is the debug report:

I know that I’m not being specific enough. I’m at a loss, so please let me know what you need to know, and I’ll do my best to fill you in.

Thanks. :smiley:


looking at your debug report, half of the ‘remote volumes’ (aka remote files on the backend) don’t have a status ‘verified’, it’s no wonder you can’t rebuild the database, basically the backend is hosed.

You did not provide any details about your backend, however it’s likely there is a problem about it and it should be solved before attempting to recreate a new backup and starting again. Maybe use the command line tool backendtester.exe ?

1 Like

I deleted all the files on the backend (Icedrive via WevDAV), and deleted the database, and restarted.

I get a popup that says, “Root element is missing.” When I click on “Show,” I see,“Failed to connect: SQLite error no such table: LogData”.

I am able to reproduce the first message by testing the connection in the backup edit dialog.

I do have the database directory and work directory moved to a local NFS mount. That hasn’t been a problem in the past. The difference from before is that Icedrive (WebDAV) is new. (Was using Dropbox before.) My initial testing with Icedrive went fine after I figured out what they needed for authentication.

deleted the database and launched a backup you mean ? I have never done that without recreating the database explicitly, well, actually recreating a new job in fact (that’s easy with export / import).

About Webdav, it’s a standard but with many implementations, maybe give a try to the backendtester tool. There has been data corruption reports with Webdav:

After reading and trying various permutations, I am unable to figure out how to invoke the backendtester tool on Linux Mint terminal.

When? After the bug report (where there seemed to be some manual deletions, but database was old)?
I’d note that “old” means only a few days though, and the database itself looks like it was from recreate.

From what? A backup after recent delete? If so does <job> → Show log → Remote show a list then?
If so, click it and see if there’s anything there. It should be empty if you had just deleted all remote files.
The question is how WebDAV is supposed to show empty – maybe nicest would be a proper empty list however I’m not sure if it’s standardized. The result looks like it sent improperly formatted XML instead.

in Advanced options on Options screen 5 (because Destination screen options get lost) might help look.
You can upload a test file that doesn’t begin with duplicati- to see if that helps the folder list quietly.

With an empty database that has finished no operations (such as backup), there’s nothing yet to show.
If that’s the problem, maybe someday Duplicati can be polished to deal with empty log more gracefully.

Sorry if I’m belaboring the obvious, but you are prefixing the exe name with 'mono ', right ?

I think the .exe file folder location varies, but if you can run which duplicati, read it as your guide. Wrapper scripts only exist for about three of the main commands. The lesser ones are more manual.