Ok, so we ruled out disk corruption, which is unusual, but great.
You can try running duplicacy in the docker container on the same server; you would not need to re-setup all schedules, only storages (IIRC due to dependency on encryption) even if that, and then copy the duplicacy.json from your windows install to the docker one.
But unless we figure out the root cause – who’s to say it won’t happen again?
I might.
When it goes to that mode, try to run the duplicacy CLI manually in the folder corresponding to the backup. What folder is that you can look up in the first line of any backup log. cd to that folder, and run duplicacy CLI binary specifying the full path to it:e.g. c:\...\.duplicacy_web\bin\duplicacy_x86_cli.exe (I’m sure I’m butchering the exe name)
See if you still get the same failure; you might get extended diagnostic information printed in the CLI, and we’ll go from there.
If it does work in CMD but fails when duplicacy_web is attempting to execute the exact same command – that would be more interesting.
Do you have (or had at any point in the past – I’m yet to see an antivirus that would properly uninstall itself) any third-party security software running? Antivirus, antimalware, any of that? It may be having a false positive: duplicacy_web is technically a trojan: it downloads executable from the internet 
and then runs it as administrator 
! Antivirus software may not like that. Maybe they get confused and start blocking it.
When that happens – try disabling your security software and see if duplicacy starts working. In which case you can add it to exceptions.
On the related note, @gchen, does duplicacy_web do anything to address DNS cache poisoning attacks? If I spoofed duplicacy.web or GitHub or whenever duplicacy_web is downloading the next version of the duplicacy_CLI and put my own very malicious executable – will duplicacy_web reject it?
Silly question - but what changed? Any software installed? Any network configuration changed? Anything else?
And lastly – maybe run MemTest, to rule out bad ram? Unlikely, but when strange stuff like that is going on it would be great to rule that out. You can download a bootable flash drive image from memtestx86.com and run it. It would be useful to confirm your ram is good regardless.
I’ve edited your title.
) in case something goes wrong. The main job of the fix flag is to make the filesystem usable by priority - even if that means loosing some data.