[Borgbackup] Is it possible to replace SOCAT with BorgMatic?

Thorsten Schöning tschoening at am-soft.de
Sun Sep 11 13:27:37 EDT 2022


Hi everyone,

I'm using PULL mode backups with SSHFS currently. There are many
remote hosts top be backed up, one backup server running BorgMatic
contain all the configs, coordinating times etc. and being the only
one with access to additionally remote sotrage for the repos themself
using SSH. Am thinking about replacing SSHFS with something like the
SOCAT example from the official docs.

https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html#socat
https://projects.torsion.org/borgmatic-collective/borgmatic/issues/584

Though, I don't like the SOCAT in that setup, because I have BorgMatic
already and have the impression that from a conceptual point of view,
it might be able replace SOCAT, acting as some write-through-proxy. To
better understand things, some questions came up for me:

1. How do Borg client and server instances communicate?

Looking at the SOCAT example and the docs of "borg serve" I have the
feeling that STDOUT of Borg client instances is forwarded to STDIN of
borg serve? Or do Borg client instances start borg serve and write
directly into STDIN of those started instances then, leaving their own
STDOUT for other purposes?

As logging is done on STDERR, it makes sense to me that STDOUT and
STDIN are free for client and server to use for their communication.

2. Who starts borg serve at all?

Looking at the logs of my existing setup, I see many commands
containing the "remote-path" argument. So Borg client instances are
running "borg serve" on their own, taking BORG_RSH etc. into account,
correct? The important point in my setup would be avoiding them doing
so, like in the SOCAT-example with a custom BORG_RSH, and instead make
BorgMatic taking care of that.

3. How does `borg serve` know about its end?

At some point the Borg client has finished. How does `borg serve`
recognized that? If BorgMatic maintains that procvess, it needs to be
able to properly stop it as well. Easiest would be if the Borg client
simply tells the process to shutdown on it's own.

Thanks!

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: Thorsten.Schoening at AM-SoFT.de
Web:    http://www.AM-SoFT.de/

Tel:   +49 5151-  9468- 0
Tel:   +49 5151-  9468-55
Mobil: +49  178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska


Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. 

Mit freundlichen Grüßen, 

Thorsten Schöning


Telefon: +49 5151 9468-55
Fax: 
E-Mail: TSchoening at am-soft.de

AM-Soft IT-Service - Bitstore Hameln GmbH
Brandenburger Straße 7c
31789 Hameln

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. 

This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. 

Hinweise zum Datenschutz: bitstore.group/datenschutz





More information about the Borgbackup mailing list