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.ziplocally, where the numbers represent the current date and time in the UTC timezone. Inside this zip archive is a single JSON file namedfilelist.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…