The original post looked like an initial backup. They can take a long time, with dlist at end.
This is a different usage (presumably) from yours which was probably an ongoing backup.
Sometimes I advise people to do initial backup in small chunks, or one might hit this issue.
Situation is not very clear on original post, and second poster looks maybe it wasn’t initial. Mysterious file loss or non-write on Google Drive. Didn’t press for a cause analysis, sadly.
Logs would probably have been obtainable then. Regardless, it’s not a common problem.
Normally the backup after an interrupted backup gets a “synthetic file list” uploaded for the interrupted backup, which is the one before it plus whatever it got done before interruption, however if there was no backup before it, it used to not do that. Not sure of current design.
Word in singular is a clue that you configured only one. There’s little point, and it’s dangerous.
Having even two versions (each additional one is usually little extra space) would reduce risk. Multiple version backup also makes it easier to restore after damage not immediately noticed.
Can’t agree with that. It’s also only as reliable as its backup storage, which is not in its control.
Unless advanced option such as no-backend-verification is set, it checks files repeatedly.
If we had the old database, we could look at the list after backup to see if it saw the dlist.
If it did, and if it gets lost later, there’s not much to do. Odd thing is if was a bad USB removal, problem seems likely to be noticed on some previous backup, with missing file error message.
That might not help if the dlist wasn’t written (e.g. unsafe removal) or was lost before copy. Probably depends on ordering though, e.g. copy (to where?) before saying done might do.
One can set this up oneself using a run-script-after which will run before the job ends, however where to store it is a good question which one can choose as desired, I suppose.
The dlist file can be pretty big, and something like copying to the database folder may fill up, breaking database use (so Duplicati in general). People already manage to fill up that space.
Clue shows up again. Another option might be to pop up GUI warning if someone picks that.
The developer doesn’t like being able to lose backups from losing one file, which is why the encryption password doesn’t do something like obtain the true key from a file in the backup. Inability to change the encryption password is itself a limitation from a security point of view.
This is all up to the developer, of course. I’m speaking mostly from seeing what goes wrong.