Here is what i do not understand. Let’s say my B2 storage is connected to Duplicacy with only keys with “add” capabilities and i prune from another machine or never. In case of ransomware this will need the “delete” key in order to encrypt my chunks/revisons? I thought it needed nothing.
More clearly i though a ransomware just needed to strike you (and your b2) start encrypting everything with or without the “delete” key. So this is wrong?
I think I finally now understood what you are asking 
So, the b2 “write” permission allows to write to files, including overwrite existing ones. Ransomware then would download your chunk, encrypt it, and upload back in place. At this point B2 will create a new version for it.
So, to be thorough, ransomware will want to proceed by deleting the previous, good version of the file. But it can’t do it without “delete” permission.
So all that you would need to do is restore all files to version 1. (That’s where your “keep all versions” setting on bucket comes in handy.
It’s a bit roundabout but b2 permissions are not fine grained enough to just forbid overwrite and be done with it, hence this dance with versioning.
Oh ok so i was wrong. I thought that ransomware scope was to just encrypt your disk and then Duplicacy will start backup encrypted stuff. So pruning the old good stuff what remains is the encrypted one.
So ransomware today is so advanced to fully interact with Duplicacy.
No, no, no,
Let’s step back.
You are right, the ransomware would encrypt your local files, duplicacy will make a backup of them or two, and it is totally harmless because you can always restore your files to their previous versions with duplicacy.
The End.
However, why stop there? if you want to take a next (albeit paranoid) step – to get absolute protection, so that even theoretically if you hand your laptop to the dude and tell him – go, nuke my data, wipe my backups, do whatever – still no data loss should be allowed to occur; that’s when all that immutable backups and restricted keys come into play.
It’s easy to imagine for smartly written ransomware to simply scrub the disk for what looks like cloud storage credentials (it reads and processes all files anyway, adding a little regex match is not a big deal), and attempt to mess with the data there. In fact IIRC something similar has already happened – some malware was targeting NAS devices from certain vendors, where people keep backups among other things.
So, for the sole reason of sleeping better at night you can accomplish that “immutability” with B2.
Should you do it? I don’t know. Probably not. Maybe yes. I’m wrong guy to ask – I never run antivirus and anti malware, and don’t stress about credentials too much, but I do run two separate backup programs to different clouds, so there is that…
Edit: in fact, this is precisely what is being discussed in this topic to begin with:
Well, a solution could be to initialize a dummy repo on an usb drive and connect the usb drive to the pc only when prune is needed.
And ransomware will wait until after you have disconnected the usb drive to start infecting things? 
Maybe encrypted VM would be better idea.
Hi, I was reading this thread and tried to configure my backups (via SMB to local NAS) to be safe against ransomware. I modified the permissions so that the user uploading data can only create files and directories, but not delete or modify existing files. From your statement it sounded like this should work (and it would effectively render any ransomware unable to destroy existing backups), but when I try to run a backup I get this output:
$ duplicacy backup -stats
Storage set to <…>
RSA encryption is enabled
No previous backup found
Indexing <…>
Parsing filter file <…>
Loaded 0 include/exclude pattern(s)
Failed to upload the chunk e710eec2ecb740699a3cf90934b865fbffeb5f5cd7200c774eafd555382a1c7e: rename <…>chunks/e7/10eec2ecb740699a3cf90934b865fbffeb5f5cd7200c774eafd555382a1c7e.bialznfj.tmp <…>chunks/e7/10eec2ecb740699a3cf90934b865fbffeb5f5cd7200c774eafd555382a1c7e: permission denied
Incomplete snapshot saved to <…>.duplicacy/cache/default/incomplete_snapshot
So for every chunk Duplicacy will create a .tmp file, write to it, and finally rename that file to get an atomic write, is that correct? In that case I wouldn’t know how to configure the read/write permissions so that a ransomware with access to the NAS cannot break my existing backups. Any help is appreciated!
This won’t work, with smb and SFTP duplicacy needs to be able to rename.
Instead, configure periodic filesystem snapshots on your NAS. If stuff gets corrupted — you’ll restore previous snapshot.
Hi again, thank you and sorry for the late reply, I was struggling quite a bit with setting things up. I now have the following setup:
duplicacy add and the key for backing up to b2 does not allow delete, only read/write)But I feel like this is not what you meant by snapshots? After all, a virus could use the stored credentials to mess with my b2 backup and restoring it would be extremely cumbersome. Could you maybe elaborate on how you’ve set things up to be resilient to ransomware/viruses?
They cannot “mess with a backup”. They can only upload additional data/make another backup of garbage, but not modify existing data. So, you just restore previous revision.
Same idea when backing up to a nas: periodic filesystem snapshots on the nas provide immutability: even though client has full access to data over SMB, including delete - filesystem snapshots still hold old data, and the user in question should not have access to delete those.