This might be part of the problem. Some problem got reported, but the other one is a crash.
If you managed to hide the database, you ran a DB recreate. I don’t think it takes that option.
Unless this was GUI Commandline or maybe the Repair button, DB location may also be off.
So the following gets amended:
but that image is from a Backup. Then there’s a repair whose log does look like a real Repair.
but if that’s this:
It seems to have a database then, as its first 4 lines complain that size doesn’t match database.
This is being reported far more often than I would like. I’m not sure devs have any good theories.
What’s on that source? I don’t know what you mean.
Remote had better not be a Duplicati backup unless the source is valid Duplicati backup files.
I’m totally lost on what you’re trying to do. Are you asking for non-Duplicati file backup ideas?
rclone sync to Storj can probably put at least one version to Storj. Sync is not well versioned.
EDIT:
If you want a versioned Duplicati backup, but Duplicati Storj works poorly (still somewhat TBD), backing up to a local drive and then doing rclone sync of that might work, but it’s pretty clunky.
To see if you really have damaged files on Storj, you could pull one down and see if it decrypts.
AES Crypt is a GUI tool, or Duplicati ships a CLI tool. I’m not sure about Docker, but Linux has:
/usr/bin/duplicati-aescrypt -> ../lib/duplicati/duplicati-aescrypt