Open dionorgua opened 4 years ago
This sounds a bit like a hack that depends on restic internal behavior that can change with any release and break such a setup. I don't think it's a good idea to support such a feature before restic itself officially supports such a setup.
I agree that this is a bit tricky, but can't say that it much different from --append-only
hack.
Whole rest-server itself depends on restic internal behavior and can't be replaced with something standard like WebDAV. Currently rest-server
has hardcoded restic repository layout (keys/locks/snapshots/data/index
), hardcoded data
layout (about one level of subdirs named with two first characters).
They were even hosted in one git repo in the past.
PS. Currently restic
doesn't properly supports --append-only
. Even after 403 error it still tries to to delete blob again and again multiple times.
@dionorgua
Did you know about the asymmetric encryption feature idea? https://github.com/restic/restic/issues/187 This would have the same results, but a lot more advantages, since this works also with other backends than rest-server.
Asymmetric encryption is related but not same..
Even if it's implemented on file/pack level it's still possible for attacker that got access to one of hosts to just delete everything on backend. append-only
+ asymmetric most likely is same as proposed write-only mode.
But it also have exactly same challenges: restic needs a way to download and decrypt current index and latest snapshot tree. Or just fallback to full backup mode in case of empty local cache.
Output of
rest-server --version
rest-server 0.9.7 compiled with go1.10 on linux/amd64
What should rest-server do differently?
Currently we've
--append-only
mode that tries to minimize risks of access to repo by attacker from compromised host.So there is no way to remove data from repo. But there is still a way to 'restore' whatever attacker wants from
--append-only
repo.It would be great to also have
--write-only
like option to completely disable read access todata
subdir. I know that restic may need it during backup, but it's actually not strictly required: usually parent snapshot is already cached. And when not cached, it's still possible to perform slower backup with--force
option that don't need that snapshot at all. Ideallyrestic
should be aware of suchwrite-only
repo and automatically fallback to--force
but not necessary.