IOerror during backup, now database not found

Hello. New user here.
My backup got interrupted by IOError, can I start over completely ?

Using Duplicati on Windows entirely through command line.
Backup source is an SMB share exposed from a linux VM hosted on the same Windows host.
Backup destination is a local HDD.
Here is the chronology.

I tried out a few commands on sample data. I’m not proud of it, but at some point I deleted the backups and the related databases and even the json manually.

Then I used the command duplicati.commandline.exe backup , to backup around 600GB of my actual valuable data. I tried the compare command and everything seemed to be in order.

Then a couple days later repeated this backup. This time I got IOError. This was probably not Duplicati’s fault, but got me worried since the backup is interrupted.

When I tried the compare command it succeeded again, and showed two versions :
Listing changes
1: 1/28/2024 9:02:53 PM
0: 1/31/2024 6:52:55 AM

I don’t see any errors in this output.

When I tried the test command, it failed with error that database doesn’t exist.

ErrorID: DatabaseDoesNotExist
Database file does not exist: C:\Users<username>\AppData\Local\Duplicati\NTZILQGXJM.sqlite

When I tried the command to delete the latest backup :
.\Duplicati.CommandLine.exe delete --version=1

It showed the same error that database is not found.

How do I recover this database, or if I cannot, then start over completely ?


using a computer to backup itself does not seem a good strategy.

I don’t understand why you did use the compare command. Why and how to compare 2 versions while you did your first backup, hence you have only one version ?

how about looking on your disk to see if this file really exists ? You are using the command line so you have to specify everything yourself, including the database location. If you are not, the database location is picked by Duplicati according notably by the user account you use so it may change from an invocation to the next.

The compare command seems to look directly at the destination dlist files. Turn on --console-log-level=information to see this. I tested using a --dbpath, and watched its work with Process Monitor.

Most commands that work with the backup are database-based, so consistently use --dbpath or use a consistent account without it. The implicit mapping of destinations (etc.) to database is in a JSON file at: