You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes (and also checked on IRC, currently the behaviour I'm looking for does not seem to exist)
Is this a BUG / ISSUE report or a QUESTION?
QUESTION (/ feature request / enhancement?)
Describe the problem you're observing.
I've setup an SSH serving host/container with BorgBackup, which is supposed to only serve borg commands (plus one command to add SSH authorized_keys). No other commands are supposed to be runable and no other SSH features are supposed to be used. Users on this host are available through a central LDAP server.
I now enforced the --storage-quota to the borg serve on this host. And would have expected this limit to be applied to this user - and not to a specific borg repsository. Now a user can just add new repositories to increase their overall quota.
I can't use the (a)quota.user filesytem feature to provide per user quotas as the Linux upstream ZFS implementation does not seem to support it and ZFS is what our Proxmox server is currently using for its containers.
It would be great if there were an option to provide a per system user quota, either as an argument to "borg serve" or more conveniently via a config file in ~/.config/borg/ and/or /etc/borg/ (and/or borgquota.{user,group} file at the filesystem root, similar to the filesystem quota feature?).
borg does not deal with "users", only with repositories.
also, there are no management commands/features for more than the "single repository" scope.
by default, it lets you create as many repos at any path you like (possibly limited by the fs permissions) and use unlimited space (as far as borg is concerned, possibly limited by fs quota).
there are these options to modify this:
limit the quota available in a repository
limit the location where a repository can be created/accessed to below some specific path
limit access to a single repository
but as you noticed, this is not implementing a "per user" quota.
one can do the following though:
limit access to a single repository per ssh key (but maybe let users use multiple keys), limit quota in that repository. if desired, bill the client per repo accordingly (either for the quota limit or for the actual disk usage of that repo). or have an overall limit and do not let the user set more than that as the sum of all repo quotas.
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes (and also checked on IRC, currently the behaviour I'm looking for does not seem to exist)
Is this a BUG / ISSUE report or a QUESTION?
QUESTION (/ feature request / enhancement?)
Describe the problem you're observing.
I've setup an SSH serving host/container with BorgBackup, which is supposed to only serve borg commands (plus one command to add SSH authorized_keys). No other commands are supposed to be runable and no other SSH features are supposed to be used. Users on this host are available through a central LDAP server.
I now enforced the --storage-quota to the borg serve on this host. And would have expected this limit to be applied to this user - and not to a specific borg repsository. Now a user can just add new repositories to increase their overall quota.
I can't use the (a)quota.user filesytem feature to provide per user quotas as the Linux upstream ZFS implementation does not seem to support it and ZFS is what our Proxmox server is currently using for its containers.
It would be great if there were an option to provide a per system user quota, either as an argument to "borg serve" or more conveniently via a config file in ~/.config/borg/ and/or /etc/borg/ (and/or borgquota.{user,group} file at the filesystem root, similar to the filesystem quota feature?).
Details on how we setup the BorgBackup server/container exactly can be found here: https://wiki.chaotikum.org/infrastruktur:host:billy:billy-borg-server-setup
The text was updated successfully, but these errors were encountered: