Can we improve the repair workflow and user interface?

I recently had a circuit trip while in the middle of a backup. My backup was seriously messed up. 51 broken files. My initial attempts at repairing things via the database -> repair and database -> recreate options did not work. Eventually I figured out I need to run the purge-broken-files command and the repair command with the --allow-full-removal flag.

End result is that I only have 1 version of my job left. Fortunately, this isn’t a big deal for this particular job, but it’s not exactly a good result.

I’d really like to see a solid user interface built into the web ui for this workflow. But I’m not the best at UI, so I’ll leave that discussion for later. In the meantime, here are a few suggestions that would have helped me.


When this error is displayed:

Fatal error
Duplicati.Library.Interface.UserInformationException: Found 51 files that are missing from the remote storage, please run repair

   at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)

   at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)

   at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)

Add information about running the list-broken-files and purge-broken-files commands. Running repair alone doesn’t seem to work. Unless the command line repair and the GUI database -> repair are actually different commands? If so, that is really really confusing…


When running list-broken-files, include information about how much of the job is broken. Something like: “N of N files broken, N of N versions unrepairable, …” Basically, information that would let a person know how bad their backup job is messed up. In my case, I would have made a copy of the remote data if I had known how much data was going to be lost.


Change how the purge-broken-files command works.

In the starting summary:

No broken filesets found in database, checking for missing remote files
  Listing remote folder ...
Marked 51 remote files for deletion
Found 23 broken filesets with 212383 affected files, purging files
Removing 23 filesets where all file(s) are broken: <truncated>

Add something about how many total files there are, and how many total filesets there are. Basically like what I described for list-broken-files.

Also, ask for confirmation before proceeding.


When using the --allow-full-removal flag, ask for confirmation, and add a message about it fully removing entire versions/fieldsets/snapshots/etc.


Also, I should note that I didn’t know Disaster Recovery - Duplicati 2 User’s Manual existed until I just went to see if anything new had been added to the docs since the last time I looked. I really wish I had thought to use the --dry-run flag… :\

I do think my ideas still have merit. Maybe the --dry-run flag could be mentioned in a few places?


Finally, thanks to the devs for making Duplicati. I’ve been very happy to have a good tool like this that isn’t going to lock me into any proprietary formats.

1 Like

Thanks for the suggestions!

I think they’re good ones, but don’t have the time to implement any of them myself. :frowning:

While not what you asked I’m a little confused about how a power outage could cause 51 destination files to disappear unless the outage happened on the destination machine and caused a drive crash.

Duplicati itself doesn’t delete “old” files from the destination until they are confirmed no longer needed (either replaced with new ones as part of a compact process or just fully aged out).

Do you have a retention policy for this backup?

1 Like

The destination was on a USB drive. Both the desktop and the drive shutdown when the power cut off.

If I remember correctly, I set that job to retain everything forever.