We’re planning to integrate restic to a shared webhosting control panel, however, we haven’t made some final decisions yet. We’d really appreciate your thoughts on the following questions:
Would you use 1 large repository per server, or many small repositories per-user? We’re losing some benefits of deduplication by creating 1 repo per-user, however, we think it’d offer more flexibility if we make it per-user (likely a higher speed, no locking, less ‘place’ for corruption to happen, as if any corruption to repo happens, it’d affect only a single user).
We’re planning to offer restores from user-level. Password file wouldn’t be readable for end-customers. It’d be the control panel taking the backup and restoring it for the user. Do you see any benefit of using different passwords per-user?
We’re planning to let customers select a single-file to restore. We’d like to avoid using FUSE mounts. Is there an easy way to list ‘1’ level of files/directories in JSON? That way we could offer some ‘navigation’ in GUI by just requesting 1 level of files directories. For example, just /home/user in the beginning, if they click “public_html” then, we’d then list all files/directories in “public_html”. That should be more efficient and speedy than just a whole list of files/directories in repot.
Is there any ETA on when compression is going to appear in Restic? (is it likely to happen in 2019?)
If there are any other suggestions, they’d be appreciated.
This is a tough question to answer without more numbers, as it will depend heavily on access patterns, number of new objects per day, etc.
If users have direct access to the repository, then it must be per-user because otherwise users could restore data of other users.
We use different keys per server in the hopes that if one server is compromised, we can delete only that key from the repository and not have to update all other servers with a new password. Different keys per user when all passwords are stored in the same database/server isn’t really useful.
Yes. restic ls --json $SNAPSHOT_ID / to get the top-level directories. restic ls --json $SNAPSHOT_ID /foo to get the contents of /foo, and so on.
Shared webhosting environments differ a lot Users would just have access in “GUI”, and backend would form a correct request for this. So, single repo is still possible. However, separate users ‘feels’ safer and isolated by design.
Yes, but just as like the above - if one password is used for all repos, and the user could somehow get the password (in theory, there should be no ways for this), he’d be able to access them all.
Great, thanks! This would simplify the things up a lot.
If all passwords are readable by the same system user then it doesn’t really matter; compromise of one password would necessarily imply ability to compromise all passwords.
Users would just have access in “GUI”, and backend would form a correct request for this. So, single repo is still possible. However, separate users ‘feels’ safer and isolated by design.