I’m testing both restic and kopia.
My biggest concern is how to implement a malware/ransomware protection for the backups.
As i’m using all instances on Google Cloud and these instances can natively access Google Storage with their default service account (in rw), let’s assume a ransomware or a deep infection on a host.
The bad user can easily drop all backups by calling restinc forget and restic prune
So, a solution could be the use of object locks on the storage with a defined policy (in example 2 months)
tried that with a standard Kopia install and it doesn’t work because indexes and other files need to be updated. I think it would be the same with restic.
So, as of today, which is the best configuration to keep backups protected from bad users ?
Something like an immutable for each snapshot. when the snapshot is taken, nobody, even restic, should be able to delete/overwrite it. (if I need to do that, i have to wait for the lock expire or remove the lock from the Google console, outside the instance)
restic does append-only backups. This means when you call backup no existing file/object in the repository is removed or changed. Only new files/objects are generated. This makes it perfectly work in combination with something like object lock or --append-only mode of rest-server.
The only thing you have to take care about: restic uses locks which do need a deletion after the operation is done. If you can configure your object lock on subpaths, exclude /locks from it and you are fine. If you can’t do this, take a look at the lock-free alternative rustic.
Even indexes and metadata are append only ? Because the bad user could drop that , yes, I have the data files but i’ll be unable to recover from them (in example because i don’t know the filename after the encryption or similiar)
Maybe things are broken now with kopia but it used to work very well. However required dedicated configuration starting with repository created with special retention mode…
Anyway - this is restic forum so if you want to try kopia then post your issues on their forum.
Thanks for your input on matters pertaining to restic. It is indeed valuable, and you provide a lot of help in many ways. However, stop using this forum as an advertisement platform for rustic. Again, this forum is about restic, not rustic. You keep overworking the amount of advertising you do here, to an extent that is not reasonable. If you want to advertise rustic more than you already are doing in the Community thread about rustic we have in place, please do so in the rustic discussions or similar.
@rawtaz I’m trying to help people to get things working - and I supposed this user forum is exactly for doing this.
Can you please suggest how I should answer people in case there are shortcomings with restic which a) affect the issue people have and b) are solved in rustic - without mentioning rustic? Thanks!
Of course crude advertising would not be acceptable but in context of problems solving IMO it is entirely fine to talk about other way to fix something.
Myself I use both restic and rustic and in my opinion they are not really competitors but very complimentary products.
There are things I can only achieve using rustic - cold storage backup or resume restore. And there are things I can only do with restic - hard links restore.
I prefer somebody to tell me you can do XYZ using rustic instead of not possible with restic today - maybe in few years time. It is laughable when such orthodox tendencies surface. What’s the point to pretend that there is nothing else outside “restic bubble”?
It is flattery really for restic that somebody decided to imitate it and in the process solved multiple issues and restic shortcomings.
What I agree is that it is indeed restic forum and not the place to discuss rustic details. But I do not see any problem with being informed that what I want to achieve is not possible with restic but is with rustic. If interested about more details I can move to rustic discussions.
My personal experience here is running backups from filesystem snapshots (like ZFS for example) - something people ask from time to time on this forum. I have tried it for some time with restic - noticed serious problems. Then discovered that it is well known issue. Discussed for the last 3 years and still without any conclusion - Restic 0.10.0 always reports all directories "changed", adds duplicate metadata, when run on ZFS snapshots · Issue #3041 · restic/restic · GitHub. And then only experimenting with rustic discovered that it can be done easily - fair enough with its own limitations etc. but for me what was important was staying with restic repo. Existence of both restic and rustic gives me even more confidence in either product - less chances that it will follow the route of so many great but abandoned open source projects. Now when I recommend restic (or maybe more and more rustic) I make it one of the key “selling points”. There are two projects I can rely on for my backups - using exactly the same repo format etc.
You need it only if you want to build your binary. Otherwise it is the same - stand-alone binary.
(for questions about rustic, please use the thread or the rustic Discussions)