While reading Is a safe `forget` command possible when the append-only client was compromised? - Getting Help - restic forum I realized I don’t know if kopia server protects (or can protect setting some configuration) a client from deleting it’s own snapshots (or mess in any way the retention policy).
I run my kopia server in a quite secure environment; but some of my clients aren’t trustworthy (and that’s the reason I take care of backups, especially in case of ransomware attack).
Yes. With kopia server you can define ACL to prevent deletion of snapshots and changing of policies.
Ok, but another concern in restic is that a user can create snapshots ahead in time; so if I create 1.000 empty snapshots, one per year, ahead in time, valid snapshots will be deleted. I don’t know who (client or server) decides snapshot time in kopia.
If one client get compromised and sends 1000 garbage snapshots, it will trigger my “last snapshots” rules, but my daily/weekly/monthly… will keep me safe.
BTW. Currently snapshot expiration/deletion in Kopia is done client-side, so by disallowing that operation, the user will accumulate snapshots forever, which is not ideal. We will need to move snapshot expiration to run server-side, and then yes - we must be careful to avoid this potential avenue of attack.
How can I disallow the deletion of snapshots? I think ransomware can still use the Kopia CLI on the client and delete snaphsots.
Are there any plans to move snapshot deletion server-side?
You have to have separated/dedicated computer where kopia would work in server mode, where you can create users with restricted ACL and use those on computer(s) you want to backup in append only mode. This only way you can prevent ransomware to erase/delete/modify existing backup because client would be ably only to push new snapshots to a server.
kopia already can work in server as well client mode, use kopia --help-long to get all details you need.
But this would mean you would need two users for every computer. One for regular use, the other one for doing things like deleting snapshots. Then you also have the problem in the KopiaUI that you actually can not change the user easily.
Wouldn’t it be better to have an additional password on client side, which needs to be typed in before you can do certain operations. Then you wouldn’t necessarily need the Kopia server and could also use something like a SFTP server.
No. You creating administrative user on a server as well restricted users (also on a server) and using those restricted user (one per computer) as a clients on computers that you want to backup. Server accepts in this way only new snapshots, no deletion, nor maintenance can be run but clients to protect all snapshot’s copies
Then you also have the problem in the KopiaUI
KopiaUI is just an Electron wrapper for kopia CLI. Open up task manager and explore command line arguments to see what actual commands/options used.
Wouldn’t it be better to have an additional password on client side, which needs to be typed in before you can do certain operations.
No. If you can do something on a client computer manually, then the same can be done by malicious program (if computer is infected, - it pretty easy to stole passwords).
Then you wouldn’t necessarily need the Kopia server and could also use something like a SFTP server.
The answer is: Why everyday hundreds new viruses/ransomwares appears and bypassing “super-duper” antiviruses and do their bad jobs?
You (as well antiviruses) can’t protect system that got infected. Everything you can do on a computer, can be done programmatically and nowadays hackers (crackers to be correct) became pretty smart. Malicious people knows that people using backup and deactivating shadow copies, encrypt or delete backup, enumerates all files and starts encrypt them from oldest one, slowly, so user can not spot such activity until only recent files get affected and even in case of offsite backup has read only mode but used limited number of copies to store (as most common online solutions do) those will be encrypted too since encrypted files pushes to repositories “officially”, so user end up with 3-2-1 encrypted by ransomware backup.
Having this administrative user how can I delete snapshots then. Can I use this administrative user on the client or on the server or on both to delete snapshots. This is not getting clear to me taking a look at the documentation:
Thanks for you support!
No, that’s the whole point - don’t trust any clients. No one computer never must not be used to login as administrative user to the server. You should run on a server as administrative user maintenance on cron that will take care about deleting old snapshots. Just setup appropriate for your use case policies - how long to keep copies of snapshots.
This is not getting clear to me taking a look at the documentation:
kopia is very flexible in setup different workflow that’s why luck of coverage of all use cases in the documentation. Documentation mostly describes backup workflows for regular, most common usage, but if you would read the whole kopia’s help you can figure out how to use it even on enterprise level, where you can backup multiple computers to the same repository and benefit from deduplication while keep backup save from deletion/encryption by malicious clients
Hi, Just FYI. I don’t think that is accurate.
If you think it isn’t accurate then run ps aux or task managed (with activated column “command line”) and see what actually is working under the kopiaUI hood. The only thing that is absent in kopia-CLI is scheduler which can (should/must) be replaced with cron/task manager which reduce memory usage as well simplify startup backup program without need for login on system with desktop environment
Just saw your response 
That, again, is not accurate either. Please see also
“jkolwaski: Looks like there’s no CLI equivalent (forgot to add it)”.
So it is pretty clear that KopiaUI is not just a wrapper for the command line version of Kopia.
Do you think that the purpose of kopia is to parse configurations (ignore/schedule) or pretend to be a cron/scheduler is the primary purpose of it instead of to be the backup?
kopiaUI is convenient wrapper on top of kopia-cli that follows proved by time old Unix wisdom - “do one thing, but do it best”. Attempting to seat on multiple chairs such as for example combining functions of schedulers that are very distinct between platforms is out of primary goal of the backup program. kopiaUI “functionalit(y/ies)” can be replaced by scripts or other wrappers that will fit precisely particular setup instead of attempting to satisfy all use cases.
Regarding “noParentIgnore”, - kopia supports the same “ignoring” format as git, so if one will create .kopiaignore file, it will work for both CLI and UI versions universally. By placing another .kopiaignore file in child directories will override parents ignoring rules
noParentIgnore is not about ignore files. It is about rules defined in the parent policy.
The point is that KopiaUI is able to set this option, but KopiaCLI is not able to set this option. Why is that? Because KopiaUI does not use the KopiaCLI to set this option. Instead it changes the json repo config file directly. That’s why “KopiaUI is just a wrapper kopia CLI” is not accurate. Having said that, KopiaCLI is actually able to read that option from the config file, it is just not able to set it. Obviously KopiaCLI should be able to set it, but the developer forgot to add it.
Please also note, I did not say your statement was “wrong”, I just said it was not accurate.
Ooh, sorry, I was too quick to reply, you right, it’s about policies, not files.
I see, thank you for clarifying it !
Is there any improvement regarding this topic in the meantime? Using the Kopia Server it would be good to have the snapshot expiration/deletion on server-side. If you use SFTP or some other cloud storage an additional protection like password on client-side would be helpful; at the moment it is just to easy to delete snapshots on client-side.