Error when switching backup server OS for the same source files

I’ve done a backup of many files from a windows share, migrated them to my Synology NAS and I want to continue the backup from the NAS running a duplicati via docker, but I get this error:

The backup contains files that belong to another operating system. Proceeding with a backup would cause the database to contain paths from two different operation systems, which is not supported. To proceed without losing remote data, delete all filesets and make sure the --no-auto-compact option is set, then run the backup again to re-use the existing data on the remote store.

I don’t want to delete and re-send the data because it would take weeks to complete.

I have a couple of issues / concerns

  1. Duplicati’s filesets are not defined anywhere that I can find with google or the user manual
  2. Several Old Threads provide options that don’t seem to exist any longer. (I have no dlist files, only dblock and dindex… no dlist)

So… I’m happy to lose the metadata, but I don’t see how. How does one follow the instructions to “delete all the filesets” that are given without losing all the remote data?
Does this need to be resolved in SQLlite now?

Thanks for any insight in advance.

How the backup process works provides a rough idea of what filelist.json in the .zip file contains:

To store the file list, Duplicati creates a file named duplicati-20161014090000.dlist.zip locally, where the numbers represent the current date and time in the UTC timezone. Inside this zip archive is a single JSON file named filelist.json, which starts out by being an empty list, which is expressed in JSON as [].

You can see how the actual OS path is used, e.g. Windows-style is "path": "C:\\data\\mydoc.txt",

That seems wrong. You have no remote backup without dlist files. The database can cover that up awhile.
How many versions does the Restore see? Ordinarily that’s the number of dlist files. Dates should match.

If you truly have no dlist files, that’s worrisome, but also the first step towards doing the Repair mentioned.
Before kicking Repair off, where is your database from? Is it a copy of the DB from the Windows system?
The reason I ask is that Repair using a DB that doesn’t match the remote backup can damage the remote.

If you’d rather just abandon the database, you can move it aside and Recreate with this experiment which sounds quite similar to the other one. Both want to reuse the source file blocks that are the same on NAS.

Either way, you lose prior version history, but I’m not sure if you have that currently. Look real hard for dlist files and at the Restore screen. If there are actually no versions, how that happened is a good question…

" How many versions does the Restore see? Ordinarily that’s the number of dlist files. Dates should match"
Thank you - somehow I missed the dlist file. There is one (and one backup version)

If you’d rather just abandon the database, you can move it aside and Recreate with this experiment which sounds quite similar to the other one
Looks reasonable… but I’ll also review the other one now that I found the dlist file.

Thanks!