Google Storage user here.
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
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.
thank you for the prompt response.
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)
i prefere restic over rustic because it’s dependancy free and doesn’t need anything extra to be installed.
rustic need rust and some other libs
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.
It is the same like to say that
go You need it only if you want to build your binary. Otherwise it is the same - stand-alone binary.
not exactly, there are some libs that would be pulled when installing rustic: https://crates.io/crates/rustic/0.1.7/dependencies
First, it is GitHub - rustic-rs/rustic: rustic - fast, encrypted, and deduplicated backups powered by Rust or https://crates.io/crates/rustic-rs.
Second, you are referring the the libraries which are used during building the binary and not needed once you obtained the binary.
And now, back to restic… (for questions about rustic, please use the thread or the rustic Discussions)
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!
Disclaimer: I speak for myself. I am definitely not @rawtaz or @fd0 or some other higher-up.
In threads NOT about rustic: Act like you don’t even know that rustic exists.
Almost. At the top of the forum page it says: “restic forum” (my emphasis)
I do not agree with neither @rawtaz nor @martinleben.
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
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
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
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.