You might want to check out the health of its drive, e.g. with smartctl or error logs.
I think sector spares might go in as NUL, but it seems unlikely to kill a whole file…
Did you keep or note original date and time, so as to get more data on its history?
Local database also keeps information, but it may disappear due to cleanup work.
Warnings and error messages from backup jobs describes a way to look into DB.
Its TimeStamp is a UNIX timestamp, so convert at epochconverter.com or similar.
You should be able to see the original upload, plus any prior downloads for testing.
Creating a bug report and posting a link to it is also an option if you prefer that way.
You’re probably making an unreliable backup that won’t restore if it needs a bad file.
The TEST command, e.g. in GUI CommandlineUsing GUI Commandline could test.
Faster is upload-verification-file, then on server use utility-scripts/DuplicatiVerify.py
The Duplicati install location may vary, but you can see if you have /usr/lib/duplicati
Assuming that means about 307 % characters at start of file. Was it random later?
You can look at some other examples, but I think encrypted files are pretty random.
Yes, good to be worried and not ignore errors in files.
Can you comment on my earlier question – how exactly are you getting right DB?
GUI Commandline? Export to true CLI? True CLI (not GUI) likely needs a –dbpath.
If you’re on GUI Commandline, then you can go to <job> → Show log → Remote
If you have a destination URL from an Export As Command-line, you can edit it for
Duplicati.CommandLine.BackendTester.exe (it needs an empty folder) and try that.
That will at least exercise the upload/download path, to eventually gain confidence.