@sternkrabbe I can understand and respect the goal for having the tunnel up and backup on the other side of the tunnel…
It’s an offsite backup (so the installation can be nuked without too much hassle)
It delivers an encrypted connection (so data want be sniffed via internet)
It saves data or power consumption (which can ease a lot of money if the installation is hardware hosted or VM hosted outside the premises).
This is a really nice workaround for not publish a WebDAV/SFTP/SMB server if not desired. But
As a sysadmin (or a supposed one like me) IMVHO should have better notes and homework done for managing own installation. Is a PITA writing down, updating, reviewing, correcting them if they are wrong. But every minute spent to make that kind of documentation about your setup counts up to 10x when it’s time to troublueshoot (and you cannot guess the obvious/immediate reason), digging up a disaster recovery, restore some important data.
In some mission critical environments, some activities like simulate a failure (shutting down something) and evaluate procedures and time spent restoring the failed piece are scheduled, audited, reported and evaluated/corrected for improvement.
The funk-up fairy (typo quite intended) is always waiting for a drone to cast the spell… Link above are my proof of dumbness. Hoping that someone will laugh my bad experiences with something new learned
Tip: consider a bandwith rule with timing for having enough bandwidth for the restore… and enough bandwidth for everything else when someone is using that connection (the one hosting the backups)