Skip to content

Set --append-only and --max-size per user #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
feuerrot opened this issue Jul 21, 2018 · 8 comments · May be fixed by #140
Open

Set --append-only and --max-size per user #74

feuerrot opened this issue Jul 21, 2018 · 8 comments · May be fixed by #140

Comments

@feuerrot
Copy link

It would be nice if I could set the --append-only option per user, to be able to backup multiple hosts, where some are trusted and should be allowed to change data afterwards (e.g. forget old snapshots) and some are not, using a single rest-server instance with a shared --path and a shared .htpasswd file.

My current solution consists of two different instances - one with the --append-only flag and one without - using two different remotes(/hostnames, using lighttpd as a proxy), two different paths and two different htpasswd files, which isn't that great.

@mholt
Copy link
Contributor

mholt commented Jul 21, 2018

To be sure I understand, are these instances operating on different restic repositories?

@feuerrot
Copy link
Author

At least for my use case: yes - every system uses their own restic repository and their own user & directory for the rest-server backend.

@feuerrot feuerrot changed the title Set --append-only per user Set --append-only and --max-size per user Jul 24, 2018
@feuerrot
Copy link
Author

--max-size seems to be another flag which would be quite useful to be able to set per user. Maybe there could be a mechanism to set arbitrary configuration flags per user?

@mholt
Copy link
Contributor

mholt commented Jul 24, 2018

I think some restructuring/redesign will be needed to make this happen, but I haven't had time to look into that.

@tcardonne
Copy link

This would be a good feature. It would be also useful to have different users for the same repository with --private-repos. For example, an user1 with --append-only (for backup tasks) and one with full access for maintenance tasks (prune/forget).

@risturiz
Copy link

Hi, if i understand correct the option "--max-size per user" is working on @wojas fork? Thanks.

@wojas
Copy link
Contributor

wojas commented Sep 27, 2022

Hi, if i understand correct the option "--max-size per user" is working on @wojas fork? Thanks.

Yes, the config file PR #140 implemented per-user configuration. I need to dust that one off and get it merged.

@deetuned
Copy link

Yes, the config file PR #140 implemented per-user configuration. I need to dust that one off and get it merged.

@wojas I built your branch and ran it using Docker Compose and it's made a huge difference to my entire backup routine across all my services! I can isolate the backups for each Docker Compose project using private per-user repos and a Restic container as one of the services in each stack (with read-only access to the Compose project directory itself), but still schedule pruning using an admin user. The Rest Server container is accessed via HTTP on a remote Pi running on an adapted NVMe, and the container is exposed only to an HTTPS reverse proxy (which itself implements access control and authentication) over Wireguard. The Restic containers point to the reverse proxy.

It seems specifying a custom htpasswd file is ignored by Rest Server, and specifying hashes via the config file doesn't seem to work, but I think this is due to the Docker build process and resultant image. I haven't had time to investigate the Dockerfile/entrypoint command. For now, using the original docker exec method to create users and store passwords in the default .htpasswd is perfectly fine. :)

Super keen to have the max-size configurable per-user too! My Nextcloud data repo eats up space, leaving no space for small service backups such as Wireguard, Homer, or Nginx.

Great work, thank you!

@pneumokoniose pneumokoniose mentioned this issue Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants