Replies: 2 comments
-
It is not clear for me what exactly you want to achieve. It is standard mode of operation for rustic that destination server (where backup is stored) does not require any password knowledge. Either you backup directly to your friend's server or replicate your local repo using |
Beta Was this translation helpful? Give feedback.
-
I don't know if I got your scenario correctly. But I would say if you trust someone to keep your data but don't trust them to access your data, just use that storage as a storage backend. rustic only stores encrypted data to the backend, so your storage provider has no access to your data. This also holds if the "storage provider" is just some friend providing you storage using a REST backend. I think this is what @kapitainsky also wants to point out... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Some less-trusted devices may be useful in a back-up scheme. For example, for offsite backups of private households, two mutually trusting households that are geographically distributed may choose to replicate the other household's backup, e.g., on an object store bucket to which they have read-only access, to some medium present at their own location. While these households trust each other, e.g. in terms of availability, this trust may not be extended to making each other privy to the the other's backups' contents. Frankly, that seems to me (West-European educated person) like a very common social standard (in my circles).
Does Rustic support this scenario? For example, by replicating a repository without entering it.
Beta Was this translation helpful? Give feedback.
All reactions