I think the cleanest recovery from this would be to NOT mix operating systems, however a search for the error message found that this has come up a couple of times, with a difficult solution involving database repair and possibly manual dlist file creation. Duplicati is not good at mixing very different operating systems, due to not only backslash direction, but drive letters and metadata, for example Windows ACLs won’t be saved on Linux.
Possible to relink an existing backup store (for pre-seeding purposes)
For background, there’s a local database (see your job’s Database option for its location) which caches info also stored in destination files, e.g. the paths backed up. It’s somewhat unusual to ask for manual deletion of destination files (as opposed to, for example, running The DELETE command) because views go out of sync, however this doesn’t matter if one plans to immediately delete the database and recreate it from destination. The theory there is probably that data blocks will be identified and then merely pointed to in the next backup as deduplication normally does. See How the backup process works. Because next backup is from Windows, the new pathnames will be done Windows-style in both the database and dlist file views. File blocks are OS-independent, but you might wind up getting lots of Windows metadata uploaded that was never done before. Simply removing the dlist file would not update the database’s view, thus producing the error message again. Operations typically use the database when possible because it’s much faster than constant destination use, however recreating a database can be slow due to the amount of destination data that must be downloaded.
Basically I’m hoping you’re willing to backup on Windows, or follow the old articles the lead author worked on. This is rather exotic stuff. Fortunately, you don’t have a huge history you need to preserve, just new backup.