Init password shared for all repositories?

[alessio.lampis]

Hello guys,
I currently backup all of my data using Duplicacy CLI and Backblaze B2 as cloud storage. I have started working in a lab where the shared computer isn’t really backed up. I set up a backup to my B2 of my files, but I created a different bucket with a separate app key for that bucket only. This probably means I’m not making good use of deduplication.

My question is this: if I create a new repository (e.g. labwork) in the same storage (same bucket) as my main backup, will this give the shared computer at work the ability to potentially prune my main backup as well? If I set a password with the init command, that applies to the whole storage, not to the single repositories, correct? I scripted the backup to happen automatically, as such I don’t want to have to enter the storage password from the shared PC every time it backs up.

[bkeeper]

@alessio.lampis

if I create a new repository (e.g. labwork) in the same storage (same bucket) as my main backup, will this give the shared computer at work the ability to potentially prune my main backup as well?

Hi Alessio,

Yes, it would.
Not only prune, but restore as well.
I would not do it.

The way to solve this is to use the RSA encryption option.
This will allow unattended backup without compromising the rest of your data.
The downside is no dedup unless you also use the same key pair for personal files.

[alessio.lampis]

I am seeing on the documentation that the prune command can be run without providing the RSA key, so this would give the shared computer the ability to delete the backups, even if it cannot restore them. If that’s the case, maybe leaving the backup on a completely different bucket is the safest choice

[saspus]

@alessio.lampis

I am seeing on the documentation that the prune command can be run without providing the RSA key, so this would give the shared computer the ability to delete the backups, even if it cannot restore them.

In fact, you don’t even need duplicacy to delete backups — just erase files via B2 api directly.

But there is a solution: create separate access keys that can only upload but not modify or delete and use them on the backup clients.

Create separate set of keys with full access and use them on one trusted machine (e.g. some cloud instance) that would be doing check and prune. More here Backup Immutability - Object Lock support? - #22 by tallgrass

[alessio.lampis]

Thank you, I think this is exactly what I’m looking for. I didn’t really look into the B2 API, so I didn’t imagine it would give you the possibility to create a more customized appkey