Agree…
Defined by how safe / good is your encryption password.
A example: you have to take care of your keyring files (if you don’t use environment variables). No one can have access to them and you should back them up by methods other than Duplicacy itself
I mentioned this before, but if the password is compromised, changing it might not make a difference (depending on how far an attacker has got access to snapshot and chunk files). I don’t think this is a problem with Duplicacy in itself or can be mitigated - choose a complex password from the outset and, aside from any coding vulnerabilities, it’s probably about as secure as it’s going to get? (This is of course assuming an attacker already has access to your local/ssh/cloud storage.)
Aren’t those partially encrypted by the OSs keyring / credential management? And do you really need to back them up? They should be recreated when you enter the master password…
I’ll do some testing on a different machine …
This is true, but in this case the attacker would already have the access to the original files, so I don’t see the point of protecting the backups.
As long as the config file is untouched (which is stored in the storage), you should be able to access the backups with the storage password.
Is my understanding correct, that without the config file, I wouldn’t be able to restore anything, even if I have my storage password?
If so, this config file becomes the most vital file in my eventually TB-sized Wasabi bucket? A missing junk could render a file useless, but a missing (or corrupt) config converts my whole backup into a brick?
If my assumptions hold true, what is the recommended way dealing with this? Copy away the config file after every backup run?
Sorry, if this is answered elsewhere, but searching for “backup” and “config” in this forum yields quite a few hits 
A write-only storage would be one way to protect it against malware. But not against hardware failure.
Edit: about immutable storage:
This is correct.
I believe Wasabi can be trusted for storing a small file that is usually not changed. If you’re really concerned, you should save this file to multiple places, like on your own computer or another cloud storage.
Wondering if we could use a config file from a bit-identical copy?
Duplicacy Add -copy (wasabistoragename) -bit-identical samename sameid C:\something\forconfigbackup
(It would not need the chunks for this purpose)
If this does not produce a reliable copy, maybe @gchen could add an option to Duplicacy for extracting a copy of the config for safekeeping. (If not the user must use other tools to do this)
I do exactly that. I have an empty extra copy (no chunks) of all the storages I use.
I set it up just at the time of the discussion above on this topic, over a year ago.
Could you elaborate? What exactly do you do? (Sorry if the answer seems obvious. It probably is for anyone using those commands on a regular basis.)
I simply created a storage copy (
add command), but I don’t create backups to that add-ed storage. So I have a copy of the config file, but there are no chunks or snapshots files.
Now I get it. That would indeed be something worth mentioning in the documentation. Not sure exactly where. One option is to mention it under the init command because people will see it there. But it wouldn’t be consistent as this is about the add command. So maybe put it there? Or create a new How to on “added security” or something.
Maybe mention in the init command page something like:
“It is important that you back up the config file that was generated on storage. If it is lost or otherwise corrupted in storage, you will lose access to your backups. You can do this by using the add command to create a copy of your storage or by directly copying the config file and storing it elsewhere off the storage (like on your own computer or another cloud storage).”
Wasn’t there supposed to be a new feature whereby Duplicacy would cache the config file locally on the client?
Also, wouldn’t it be a good idea for the init, add and password commands - anything that writes to the config file in the storage - to also create a config.bak in there as an extra precaution? And if amending an existing config, to put the previous copy as config.old?
Thank you for your insights, @akvarius, @gchen, @towerbr, @Christoph and @Droolio. Very helpful.
I have no reason to not trust Wasabi to take care of the config file. I am more concerned about myself making a mistake (the sort of “oh, I thought this was my test bucket in this window here” or inadvertently triggering the wrong command from shell history).
It’s more of an operational thing than security related, IMHO (my mistake of course, since I hijacked the thread).
I like Droolio’s idea of storing the config redundantly on the remote storage. Why not put a verbatim copy of the config file in every of the 256 top level chunk folders? Would add a mere ~ 350 KB of data, but a lot of resiliency.
I agree,
We could implement auto-backup for the app and storage config.
Add the option to include logs. (which would compress really well)
backup to storage or local zip.
Nice idea! +1 for this feature. 
I fully agree with your comment: as long as the storage is accessible from the client machine only some sort of write-only mechanism on the storage machine itself may help against typical malware/client breach/password re-use scenarios. This is THE major problem of push backups to storage backends and a real show stopper for many backup strategies.
I’m currently using duplicacy to backup to a storage on a freenas box which gives me the possibility to “freeze” the storage by creating ZFS snapshots of the storage. In case of a breach on the client machine the attacker could delete the whole storage and I would still be able to roll back the ZFS snapshots to the point in time when the storage was intact.
Another possibility would perhaps be to have a daily task running on the storage system which changes user permissions on the storage files to read-only for the backup user and do a chown in order to keep the backup user from changing permissions. According to my understanding this would only harm “prune” commands because the “backup” commands will only add files to the storage.
On Linux you should be able to set immutable attribute: chattr +i backup/, root is required to do that and then only reset it for a period of time when prune is running (perhaps on the storage server itself).
After some time, I have re-arranged my backups. I’m now using duplicacy to backup from NAS1 to NAS2 via sftp wherein the sftp user is called backup.
Using your suggestion on the immutable attribute, a root cronjob on NAS2 executes the following commands:
chown -R root:backup *
chmod -R 755 *
find . -type d -print0 | xargs -0 chmod 1775
The last command sets the so called sticky bit for all directories of the storage. Thereby only the owner, which is now root, can delete or change files within that directory. Because the backup user is in the backup group, NAS1 connecting via the backup user can still add new files with the next dulicacy backup run.
The prune command is running as root on NAS2. For this purpose I had to set up a local repository (source) which is more or less empty but is connected to the same storage (target) to which NAS1 is connected. Using the “prune -all” allows to prune the snapshot revisions from the NAS1 backup.
Hope this helps some people to set up a backup which survives a malware attack or a breach.
Any further suggestions are always welcome.