Found XX files at the remote storage, but none that could be parsed

onurbi · April 19, 2026, 9:57am

Hi,
after updating to 2.3.0.0 (Stable) 2026-04-14 I am not able to backup anymore.

Trying to backup via my everytime successful cmd batch I got:

=> The database was attempted repaired, but the repair did not complete. This database may be incomplete and the backup process cannot continue. You may delete the local database and attempt to repair it again.

Then I tried to repair and got the mentioned error message.

Then I added the option --rebuild-missing-dblock-files=True in my batch file.

Result:

Backup started at 19.04.2026 12:13:58
Checking remote backup …
Listing remote folder …
Extra unknown file: duplicati-20260419T081923Z.dlist.zip
…

Missing file: duplicati-ba3eaf626292748efbf4e256093b1505b.dblock.zip
…

Die Operation Backup ist fehlgeschlagen => Found 8 remote files that are not recorded in local storage. This can be caused by having two backups sharing a destination folder which is not supported. It can also be caused by restoring an old database. If you are certain that only one backup uses the folder and you have the most updated version of the database, you can use repair to delete the unknown files.

ErrorID: ExtraRemoteFiles
Found 8 remote files that are not recorded in local storage. This can be caused by having two backups sharing a destination folder which is not supported. It can also be caused by restoring an old database. If you are certain that only one backup uses the folder and you have the most updated version of the database, you can use repair to delete the unknown files.

Reading similar postings did not help me.

My setup uses a local USB HDD.

Any ideas what next step helps?

Regards,

Onurbi

ts678 · April 20, 2026, 1:49pm

Do you specify --dbpath explicitly on the command? That makes it easier to

So you didn’t delete local database first? If you need path, read dbconfig.json.

Some backup ran (time is UTC), but the database you’re in didn’t hear about it.

This is important. Are you certain of that? Did anything else change at upgrade?

onurbi · April 20, 2026, 3:29pm

Yes, I did.

I tried this with no success several times.

Yes I deleted it. Manually and via GUI.

Of course, and am sure.

To cut a long story short, I decided to discard the accumulated versions and started a new backup in a new directory. That worked.

But basically, the repair function should be able to regenerate a database on its own using just the existing ZIP files. Or did I overlook something?

ts678 · April 20, 2026, 7:41pm

Not repair, but delete and repair should be able to do that from good destination.
Destination can be broken (e.g. trash lots of files), so can have recreate failures.

Complaint about excess or missing files are comparison of DB to destination, so

should not have been possible if the database had been deleted before a repair.

If problem is reproducible, one could look at file times and dlist UTC times to attempt to figure out what happened. Something touched DB or the Destination.

If that means the old backup was discarded, further research may be impossible.

In other oddities, the “none that could be parsed” message in title wasn’t detailed
to say when it happened, but other output was puzzling enough. The source code

github.com/duplicati/duplicati

Duplicati/Library/Main/Operation/RecreateDatabaseHandler.cs

a2b5721e6


      
          var rawlist = await backendManager.ListAsync(m_result.TaskControl.ProgressToken).ConfigureAwait(false);

          

          //First step is to examine the remote storage to see what

          // kind of data we can find

          var remotefiles =

          (from x in rawlist

           let n = VolumeBase.ParseFilename(x)

           where

               n != null

                   &&

               n.Prefix == m_options.Prefix

           select n).ToArray(); //ToArray() ensures that we do not remote-request it multiple times

          

          if (remotefiles.Length == 0)

          {

              if (!rawlist.Any())

                  throw new UserInformationException("No files were found at the remote location, perhaps the target url is incorrect?", "EmptyRemoteLocation");

              else

              {

                  var tmp =

This file has been truncated. show original

looks to me like it was looking at a folder without any of the usual duplicati files,
all beginning with duplicati, then being dblock, dindex, or dlist, and at
end being .zip and possibly .aes or .gpg after that. What it actually saw is
recorded in the job database as a list entry, so possibly is still researchable.

The GUI is easiest way. Job → Log → Destination shows all the activities there.

These run the risk of drive letter assignment and maybe wrong files being seen.
To me (maybe dev can say more), these are strange results, with little to look at.
If you have enough left to try, we could, otherwise I’m just glad it’s running again.

onurbi · April 20, 2026, 8:58pm

No, I saved the previous folder content. It is still available.

I could run some targeted tests using a new database name.

In principle, you’re right. In my case, however, the drive letter hasn’t changed.

Yes if you have an idea how to approach the investigation.

ts678 · April 20, 2026, 9:27pm

Try to make it fit the model. If it has knowledge of expected files, that strongly suggests there’s still a database around unless the code is tripping over itself.

--log-file=<path> and --log-file-log-level=information (or verbose, or even profiling which is huge) provide information showing destination files or more.

If an error comes up naming missing or extra a file, one could look over history of the file. If in GUI, you do that as I said for list, but an upload is a put operation, download is get, delete is delete and would be interesting for missing file error.

This can also be seen in the log, but if you don’t have one set up, database can do. Possibly it’s even in an old one you kept, but reproducing an issue might be easier.

Maybe the dev will show up at some point with further ideas on what went on there.

onurbi · April 20, 2026, 10:03pm

I’ll give a try with the suggested log parameters tomorrow.