GB-TRANSFER-SERVIC(1)

πŸ“¦
version 0.5.0 Β· 3 versions
, in ubuntu resolute, ubuntu stonking

πŸ’– GB-TRANSFER-SERVIC(1) β€” the girlies' guide to gb-transfer-service πŸ’–

okay so bestie, welcome to the User Manual for gb-transfer-service, living in section 1 of your local man pages. grab a snack, this is gonna be cute AND useful. πŸŽ€


✨ NAME ✨

gb-transfer-service β€” synchronise guerillabackup backup data storages. that's it, that's the vibe. πŸ’…


🌸 SYNOPSIS 🌸

gb-transfer-service --Config file

πŸ¦‹ DESCRIPTION πŸ¦‹

heyyy so this is the manual page for the gb-transfer-service command. for more details (and there ARE more details), go look at the packaged documentation at /usr/share/doc/guerillabackup. πŸ“š

this service is lowkey doing two main things, and both of them are iconic in their own way:

  1. it provides a stream-based protocol so it can talk to other gb-transfer-service instances, like a little group chat but for backups.
  2. it applies storage and retrieval policies for data synchronisation. the rules of the friend group, fr fr.

the network part β€” listen up β€” uses a local AF_UNIX socket to listen for incoming connections (that's /run/guerillabackup/transfer.socket, more on that under FILES below πŸ‘‡).

🚨 important: there is no authentication magic and no likely-to-be-flawed custom-made crypto baked into that part. zero. none. any process that's allowed to open the socket can talk the protocol. periodt.

so for connectivity and authentication, bestie, use your favourite (trusted) tools. good starting points:

  • socat with OPENSSL X509 client/server certificate checks on one side
  • UNIX-CONNECT:/run/guerillabackup/transfer.socket on the other one

and if you're using SSH to forward these connections? you should consider key-based authentication with command forcing, like this:

command="/usr/bin/socat - UNIX-CONNECT:/run/guerillabackup/transfer.socket"

...plus the default security options (restrict). πŸ”’ that's the move, no cap.


the policies part β€” this is the other whole domain of gb-transfer-service, and honestly? it's giving gatekeeper energy. πŸ‘‘

policies define the authorisation rules granting access to backup data elements. but listen: they do NOT grant access to the remote file system as such, and they do NOT allow creation or restore of backups. nope. that's the domain of the gb-backup-generator tool. stay in your lane, policies.

the policy also defines which backup elements should be copied or moved to other storages. and here's the tea: each gb-transfer-service may have two policies β€”

  • one defining what should be sent to other instances (the sender policy) πŸ“€
  • and one defining what should be received (the receiver policy) πŸ“₯

and if you don't define a policy for a transfer direction? no data will be sent in that direction. nothing. silence. the void. πŸ’€

currently there are two predefined policies, and they're both kinda slay:

  • ReceiverStoreDataTransferPolicy: this policy attempts to create a copy of each file offered by a remote sender and keeps it, even after the sender stopped providing it. this one is useful to fetch all files from a remote storage. it's a collector, a hoarder, a keeper of memories. 🫢
  • SenderMoveDataTransferPolicy: this policy offers all backup files in the local storage for transfer. depending on the settings, files are deleted after sending, or just flagged as sent after successful transfer. πŸ‘€ choose wisely.

a policy implements one of the policy interfaces, which are ReceiverTransferPolicy and SenderTransferPolicy. and if the predefined ones don't match your requirements? you may create a custom policy. main character move, honestly. ✨


πŸ”₯ OPTIONS πŸ”₯

  • --Config file β€” this optional parameter specifies an alternative configuration file instead of /etc/guerillabackup/config. yes bestie, you CAN have options. one option, actually. she's an only child and she's thriving. πŸ’…

πŸŽ€ FILES πŸŽ€

  • /etc/guerillabackup/config β€” the main configuration file for all guerillabackup tools. to create it, use /etc/guerillabackup/config.template. πŸ“ the template also contains the documentation for each available parameter (bless, no guessing games). the most relevant parameters for gb-transfer-service are:
    • TransferServiceStorageBaseDir
    • TransferReceiverPolicyClass
    • TransferReceiverPolicyInitArgs
    • TransferSenderPolicyClass
    • TransferSenderPolicyInitArgs
  • /run/guerillabackup/transfer.socket β€” this is the default socket file name used to connect two gb-transfer-service instances. 🧚 the path can be changed by modification of the "GeneralRuntimeDataDir" configuration property from its default of "/run/guerillabackup".

by default, the socket is only accessible to privileged users and the user who created it (mode 0600). you might change permissions after startup to grant access to other users also β€” your socket, your rules. 🌈


πŸ™ˆ BUGS πŸ™ˆ (not the cute kind)

for guerillabackup setups installed from packages β€” like .deb or .rpm files, usually installed via package management software such as apt-get, aptitude, rpm, yast β€” please report bugs to the package maintainer. πŸ“¦

for setups from unpackaged software trunk, please report at:

https://github.com/halfdog/guerillabackup/issues

πŸ‘‘ SEE ALSO πŸ‘‘


πŸ’œ AUTHOR πŸ’œ

halfdog <me@halfdog.net>

  • Wrote this manual page. (ty for your service, legend 🫑)

Copyright Β© 2016-2023 halfdog

This manual page was written for guerillabackup system on Linux systems, e.g. Debian. 🐧

Permission is granted to copy, distribute and/or modify this document under the terms of the Lesser GNU General Public License, Version 3.

On Debian systems, the complete text of the Lesser GNU General Public License can be found in /usr/share/common-licenses/LGPL-3.


okay that's the whole page bestie!! πŸ’– this one ships out from guerillabackup, dated 01/21/2026, and it's filed under GB-TRANSFER-SERVIC(1) in the User Manual. you're gonna do amazing things with your sockets. iykyk. πŸ¦‹βœ¨πŸ‘‘

πŸ“¦ where this page comes from