"Is borg working on the server?"

Question

I'm trying to setup an automated backup system to backup my Raspberry Pi's data to my Mac Mini. However, calling neither borg init nor borg create from the RPi to the remote Mac Mini repo host seems to reach the borg server running on the Mac Mini. On the Mac Mini:

% sudo borg serve --debug --restrict-to-path /Users/borg/BorgRepos/RetroPie
$LOG DEBUG borg.logger Remote: using builtin fallback logging configuration
$LOG DEBUG borg.archiver Remote: 33 self tests completed in 0.12 seconds

On the RPi:

$ sudo borg create --debug --stats borg@octolen:/Users/borg/BorgRepos/RetroPie2::Friday2 RetroPie
using builtin fallback logging configuration
35 self tests completed in 0.59 seconds
SSH command line: ['ssh', 'borg@octolen', 'borg', 'serve', '--umask=077', '--debug']
Password:
Remote: zsh:1: command not found: borg
Connection closed by remote host. Is borg working on the server?
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/borg/archiver.py", line 4455, in main
exit_code = archiver.run(args)
File "/usr/lib/python3/dist-packages/borg/archiver.py", line 4387, in run
return set_ec(func(args))
File "/usr/lib/python3/dist-packages/borg/archiver.py", line 134, in wrapper
make_parent_dirs=make_parent_dirs, args=args)
File "/usr/lib/python3/dist-packages/borg/remote.py", line 577, in __init__
raise ConnectionClosedWithHint('Is borg working on the server?') from None
borg.remote.ConnectionClosedWithHint: Connection closed by remote host. Is borg working on the server?
Platform: Linux retropie2 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l
Linux: debian 10.13 
Borg: 1.1.9 Python: CPython 3.7.3
PID: 28539 CWD: /home/pi
sys.argv: ['/usr/bin/borg', 'create', '--debug', '--stats', 'borg@octolen:/Users/borg/BorgRepos/RetroPie2::Friday2', 'RetroPie']
SSH_ORIGINAL_COMMAND: None

I did add /usr/bin/borg to the Mac's firewall's list of applications permitted to allow incoming connections. What am I missing here?

Answer 1

The Objective: setup an automated backup system to backup my Raspberry Pi's data

I don't know anything about "borg", so this answer will address the objective. If "borg" is a requirement, you can stop reading here.

There is a backup solution that is specific for the RPi called image-backup. It's been around for a while, it is well-supported by the author, and it is easily automated. I have automated my backups using image-backup with a very simple script I schedule as a cron job from my RPi.

There have been several Q&A here on RPi SE that reference it (for example], or you can do your own search.

In my case, I create a "new-from-scratch" backup image every 4-8 weeks, and then update this "master" image using a script I run from the root crontab. I have placed all the image-backup scripts in /usr/local/sbin.

I update my backup images using the following script (also kept in /usr/local/sbin):

#!/bin/bash
filename: updt_img_bkup.sh
bash script to update image-backup images
this script scheduled via root's crontab
image file name prototype:
/mnt/SynologyNAS/rpi_share/raspberrypi3b/20220715_Pi3B_imagebackup.img
IMG_ROOT_LOC=/mnt/SynologyNAS/rpi_share/
HOSTNM=$(cat /etc/hostname)/
IMG_TO_UPDT=$IMG_ROOT_LOC$HOSTNM$(ls -1tr $IMG_ROOT_LOC$HOSTNM | tail -n 1)     # update the latest file
BASE_NM=$(basename $IMG_TO_UPDT)
LOG_LOCATION=/home/pi/imagebackup.log
DRY_RUN=1       # 0 ==> dry-run, 1 ==> update backup image
printf "====> begin log entry for $0 <====\n"
printf "Commence $BASH_ARGV0 at datetime: $(date -u)\n"
Verify the image to be updated is available:
if [ ! -f $IMG_TO_UPDT ]; then
   printf "\nBACKUP FAILURE: ON $(date -u), $0 FOUND NO IMG FILE TO UPDATE 

AT LOCATION $IMG_TO_UPDT\n" | tee -a /etc/issue.net $LOG_LOCATION
   exit 1
fi
if [ $DRY_RUN -ne 0 ]; then
        # Write an entry to the log:
        printf "$BASH_ARGV0 - begin update of backup image: $BASE_NM, date-time: $(date -u)\n"
        # Update the backup image with the 'image-backup' script:
        /usr/local/sbin/image-backup $IMG_TO_UPDT
        RTN_CODE=$?
        if [ $RTN_CODE -eq 0 ]; then        # updated backup successful
                printf "RESULT: Succesful update of backup completed at: $(date -u)\n"
                printf "Updated backup image: $(ls -l $IMG_TO_UPDT)\n"
        else                         # updated backup failed
                printf "ERROR: image-backup RTN_CODE is $RTN_CODE; $BASH_ARGV0 FAILED to update $IMG_TO_UPDT\n" | tee -a /etc/issue.net
        fi
else
        printf "DRY_RUN invoked; NO UPDATE on $IMG_TO_UPDT\n"
        printf "END DRY_RUN value is: $DRY_RUN\n"
        printf "ENDING DATE-TIME: $(date -u); script: $BASH_ARGV0\n"
fi

One line in the root crontab runs the script above on a schedule. The crontab entry also creates a log. Here's how:

$ sudo crontab -e
add the following line:
0 13 * * 0,2,5 /usr/local/sbin/updt_img_bkup.sh >> /home/pi/imagebackup.log 2>&1 

This can easily be adapted to a number of situations; I will leave it to you to get the backup image file (*.img) to your Mac Mini. The *.img file created in this way can be used to do a complete restoration of your system by burning it to an SD card, or it can be mounted in a Linux system for access to individual files. There are two partitions in the image file: a FAT partition whose root is /boot, and an ext4 filesystem whose root is /. /boot can be read and edited on your Mac, the ext4 partition cannot. If, for some reason, you need a backup of specific files that reside on the ext4 partition, I'd suggest you use rsync for that purpose.

Answer 2

There is no need to start "borg serve" manually on the repo server because the borg client invokes that command via ssh and then talks to it via stdin/stdout/stderr.

Remote: zsh:1: command not found: borg

That means that borg is not in the PATH on the repo server (for the ssh session created by the borg client).

So, borg is NOT (yet) working on the server.

https://twitter.com/pi_stack/status/1606668460074958849 < hehe

borg 1.1.9 is rather old btw and only safe if it is a patched version (like in debian). check if you can get a more recent version (e.g. from debian backports).