Open calestyo opened 1 year ago
In addition to that the following would be nice, too:
If ssh_filter_btrbk
would allow to specify the target root path and btrbk.conf
would allow to specify a relative target path.
The idea is, that one wants to prevent that any backups pushing host can write to any location with --restrict-path
... but if a path is anyway already enforced for a given SSH key (and thus backuping host), one could as well use that as the target location.
E.g.
command="ssh_filter_btrbk.sh --target --delete --restrict-path /mnt/btr_backup --relative" ssh-rsa AAAAB3NzaC1...hwumXFRQBL btrbk@the-hosts-that-pushes-backups-to-this-host
WIth --relative
meaning that all target paths from the pushing host go relative to --restrict-path
.
With this one wouldn't even need any %h
to be used, but of course it might still be useful for people that don't use the SSH wrapper.
Hey.
For pathnames, and there especially for the target pathnames it would be nice if one had format-string-like fields.
Consider e.g. on has multiple hosts that run backups all to one backup server and one wants to use an identical
btrbk.conf
for all of them.It would be nice if one could say e.g.:
and that would automatically resolve to the FQDN of the sending host.
Similar, one could use
%s
for the short hostname,%u
for the sending username (not sure whether that would make sense in practise).For the other way round, i.e. a backup host pulling volumes from remote to local, the same could be done, and e.g. the hostname taken from the current section’s
ssh://
URI.Fields for that could use capital letters instead (e.g.
%H
for FQDN).The reason why I'd differ, and not just use
%h
for both is, that somedaybtrbk
might wish to implement "3rd party" functionality, wherebtrbk
runs on a host, which is neither source, nor target, but just initiates the stuff on both sides.Cheers, Chris.