Release 1.4.0

[ThomasWaldmann]

borgbackup 1.4.0

First release for the new 1.4-maint branch.

borg 1.4 is kind of a refreshed 1.2 with mostly the same features and behavior, but a few bigger changes that could introduce issues and thus were not suitable for just releasing them as 1.2.x, but rather needed some testing first.

Long changelog:

https://borgbackup.readthedocs.io/en/1.4.0/changes.html#version-1-4-0-2024-07-03

Short borg 1.4 overview (from a borg 1.2 perspective):

https://www.borgbackup.org/releases/borg-1.4.html

Installation

If you use pip to install this, use: pip install "borgbackup==1.4.0"

For other installation methods and more details, please see: https://borgbackup.org/

See also the 00_README.txt file in the assets list below for a description of the available "fat binary" downloads.

---

This discussion was created from the release Release 1.4.0.

[bbx0]

Cool, thanks! 🥳

If someone wants to try it in Docker, I just updated my pipeline bbx0/container-borgbackup for 1.4 as well.

[vbc4ejyg]

RE: "Use a ephemeral container (--rm)."

Can you please tell me how to export all my variables when doing this method? Typically with a fat bin I would just call it directly on my NAS through a script and export all variables within shell. Variables I specify in the script.sh are:

BORG_REPO, BORG_PASSPHRASE, BORG_RSH (to specify the id_ed25519 key to allow passwordless ssh connection).

Within script I also use some $TMP log files, that when finished, bundles everything together and sends me an email of the backup logs. Is this possible using an ephemeral container? And if not, is there a way to use your container to kick off the .sh script I already use via mounting all the shares to backup as ro? I looked over the docker hub and didn't see how to do this.

Thanks.

[bbx0]

Sure, I guess this would work. You can wrap the call to the container in a function to replace the borg command and likely keep most of your script. Shell redirection (to collect logs) also works with a container.

Off the top of my head it can look like this. You can also write --env=BORG_PASSPHRASE instead of --env=BORG_PASSPHRASE="mypass" to provide an existing env variable to the container.

#!/usr/bin/env bash
set -eu -o pipefail

# Borgbackup container wrapper
# - Remote repo connected via ssh (key mounted as /mnt/id_privatekey)
# - Source folders mounted under /mnt/src/
function borg-container {
	docker run \
		--name borgbackup \
		--rm \
		--quiet \
		--userns=host \
		--env=BORG_HOST_ID="script.sh@$(hostname --fqdn)" \
		--env=BORG_PASSPHRASE="mypass" \
		--env=BORG_REPO=ssh://remotehost \
		--volume=/root/.ssh/id_privatekey:/mnt/id_privatekey:z,ro \
		--env=BORG_RSH="ssh -i /mnt/id_privatekey -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR" \
		--volume borg:/borg \
		--workdir /mnt/src \
		--volume=/sourcedir1:/mnt/src/sourcedir1:z,ro \
		--volume=/other/sourcedir2:/mnt/src/other/sourcedir2:z,ro \
		bbx0/borgbackup:1.2 "$@"
}


# Run the function instead of the borg command
borg-container --version
borg-container info
borg-container list ::
borg-container create --list ::{now} sourcedir1 other/sourcedir2 2>> mylog.txt

[vbc4ejyg]

For completeness on this thread, here is what it takes to get this running on a QNAP TVS-872XT, v1.4.1.0 via Docker thanks to @bbx0:

#!/bin/bash

        docker run \
                --name borgbackup \
                --rm \
                --quiet \
                --read-only \
                --userns=host \
                --hostname=QNAP \
                --env=TZ=America/Chicago \
                --env=BORG_HOST_ID="script.sh@$(hostname --fqdn)" \
                --env=TMPDIR=/dev/shm \
                --env=BORG_PASSCOMMAND \
                --env=BORG_REPO \
                --env=BORG_BASE_DIR \
                --env=BORG_RSH="ssh -i /run/secrets/borg.sshkey -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR" \
                --workdir /share \
                --volume=/share:/share:ro,z \
                --volume=$BORG_BASE_DIR:/borg \
                --volume=/share/homes/admin/.ssh/id_ed25519:/run/secrets/borg.sshkey:ro \
                --volume=/root:/root:ro \
                --volume=/mnt/HDA_ROOT:/mnt/HDA_ROOT:ro \
                bbx0/borgbackup:1.4 "$@"

1. Place docker code into a file called "borg" and store in bin path /usr/bin, or /opt/bin if entware is installed
2. Set ENV variables as normal within your regular backup script which can passed into the container if called:

https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables

export BORG_BASE_DIR=/share/CACHEDEV2_DATA/.borg.cache   ## set to a persistent location directly on a CACHEDEV DATA folder on the NAS that is not managed by the QNAP GUI, therefore no risk of deletion
export BORG_REPO="ssh://borg@mydomain.com/Borgpool/`hostname`"   ## if using ssh on remote host, set repo path
export BORG_RSH="/opt/bin/ssh -i /share/homes/admin/.ssh/id_ed25519"    ## set to your keypath as needed
export BORG_PASSCOMMAND="cat /path.to.keys/passphrase-file"  # set to your passphrase file

3. Execute your script as if it were a direct bin (borg mybackupscript.sh) and call the /usr/bin/borg docker directly inside your backup script

Also just FYI that QoolBox did eventually release a precompiled v1.4.1.0 bin that works, but with Docker you now have options to run it either way.

https://www.myqnap.org/product/borg-backup/

[garret]

May I ask for a similar approach but where I need to run this image in a borgbackup server instead?

I have pc that acts as a borg client (x86_64 with borg 1.4.1) and a server running on a Raspberry Pi with an old version of Debian (arm64 with borg 1.4.0). I would like to use this docker image to kind of have 'borg 1.4.1' on the raspberry pi 'server'.

Would it be correct to just create and chmod a file /usr/bin/borg on the server and inside putting something like this:

#!/bin/bash

        docker run \
                --name borgbackup \
                --rm \
                --quiet \
				--user 1001:1001 \
                --env=TZ=Europe/Rome \
                --env=BORG_HOST_ID \
                --env=TMPDIR=/dev/tmp \
                --env=BORG_PASSCOMMAND \
                --env=BORG_REPO \
                --env=BORG_BASE_DIR \
                --env=BORG_RSH \
				--volume=/home/myusername/ssd/backup:/home/myusername/ssd/backup \
                bbx0/borgbackup:1.4.1

The volume /home/myusername/ssd/backup is where I told in my client script to save the backup on the raspberry pi server.

Do you think the script above could also work without passing any of the --env variables?

The --user 1001:1001 is to be sure that borg runs as the main user of the Raspberry Pi but don't know if this is the right approach and could mess up some permissions? As I wrote in the beginning, at the moment I have a binary of borg 1.4.0 and don't know how this acts in terms of file permissions.

[yrro]

Congrats on the release. And thanks for the glibc 2.28 compatible binary!

[debuglevel]

Thanks for the new naming scheme :D

[ThomasWaldmann]

Bad news for freebsd 13 users: #8269

[FelixSchwarz]

I pushed borgbackup 1.4.0 to Fedora rawhide. F39+F40 will stay with borgbackup 1.2.x. Let me know if there is interest in a COPR repo which provides borg 1.4 for F40.

[vbc4ejyg]

Will it be possible to have a fat bin "borg-linuxold64" for use with a NAS on glibc 2.21? Borg-1.2.8 and prior have the old fat bins. I've been using borg on a QNAP NAS forever, and hoping this isn't the end of the line without extra work such as a container.

admin@TVS-872XT:~$ ls -al /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libc*
-rwxr-xr-x 1 admin administrators 1767856 2020-09-17 02:09 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libc-2.27.so*
lrwxrwxrwx 1 admin administrators      16 2024-02-06 13:17 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcbor.so.0.8 -> libcbor.so.0.8.0
-rw-r--r-- 1 admin administrators   59680 2023-09-01 14:07 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcbor.so.0.8.0
-rwxr-xr-x 1 admin administrators  194800 2020-09-17 02:09 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcidn-2.27.so*
lrwxrwxrwx 1 admin administrators      15 2024-02-06 13:02 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcidn.so.1 -> libcidn-2.27.so*
lrwxrwxrwx 1 admin administrators      17 2024-02-06 13:19 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcom_err.so.0 -> libcom_err.so.0.0*
-rwxr-xr-x 1 admin administrators   18776 2023-05-26 17:50 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcom_err.so.0.0*
-rwxr-xr-x 1 admin administrators   43216 2020-09-17 02:09 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcrypt-2.27.so*
-rw-r--r-- 1 admin administrators 4280480 2024-02-12 03:54 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcrypto.so.3
lrwxrwxrwx 1 admin administrators      16 2024-02-06 13:02 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcrypt.so.1 -> libcrypt-2.27.so*
lrwxrwxrwx 1 admin administrators      12 2024-02-06 13:02 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libc.so.6 -> libc-2.27.so*
lrwxrwxrwx 1 admin administrators      16 2024-07-27 13:49 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcurl.so.4 -> libcurl.so.4.8.0*
-rwxr-xr-x 1 admin administrators  530056 2024-02-22 12:13 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcurl.so.4.8.0*
lrwxrwxrwx 1 admin administrators      17 2024-07-27 13:50 /share/CACHEDEV1_DATA/.qpkg/Entware/lib/libcurses.so -> libncurses.so.6.4*


admin@TVS-872XT:~/1$ ldd --version
ldd (GNU libc) 2.21
Copyright (C) 2015 Free Software Foundation, Inc.

I know, ouch.... libc-2.21. Nonetheless, it's been easy running the fat bins straightaway.

Anything newer is:

admin@TVS-872XT:~/1$ ./borg-linux64

[14875] Error loading Python lib '/opt/tmp/_MEIzelWIZ/libpython3.9.so.1.0': dlopen: /lib/libc.so.6: version GLIBC_2.28' not found (required by /opt/tmp/_MEIzelWIZ/libpython3.9.so.1.0)

Thanks.

[bbx0]

I had some success using StaticX in the past and packaged up a static binary borg-1.4.0-amd64.zip (without FUSE). Feel free to try it.

Not sure though, if StaticX would be a mature enough option to be considered for in the general releases.