Hach ja, wenn Theorie und Praxis mal passen würden. Bei vielen meiner Server bietet der Anbieter einen kostenfreien Backupspeicher an. Gut, ob man dem Vertraut steht wo anders, aber eine weitere (verschlüsselte) Kopie kann ja nicht schaden, richtig?

Am schönsten wäre es für mich Borg einfach ein weiteres Repo auf dem Backupspeicher anlegen zu lassen. Leider gibt es da ein Problem: Der Anbieter bietet den Zugriff nur per FTP an, welches von Borg nicht nativ unterstützt wird.

Zwar ist es mit curlftpfs möglich den Server als lokalen Ordner einzubinden, allerdings unterstützt der Dateisystemtreiber viele Standardoperationen nicht wirklich und hat seit 2008 kein Update mehr gesehen. Mangels Alternativen bleibt wohl nur herumbasteln. Leider konnte ich mit keiner noch so exotischen Kombination – egal ob mount-Parameter oder loop-Devices – eine Funktionierende Umgebung für Borg kreieren, also muss ein weiterer Umweg als Workaround her.

Da lokal genug Platz vorhanden ist lautet das Konzept: Borg sichert in einen lokalen Ordner, der wird dann auf den FTP gespiegelt. Klarer Job für rsync, oder? Naja, sieht die Software anders:

rsync: mkstemp "/mnt/backup/ftp/repo/data/0/.1290.dU25tM" failed: Operation not supported (95)

Glücklicherweise betrifft das Problem wohl ausschließlich die mkstemp-Funktion, welche rsync nur für temporäre Kopien benötigt. Diese werden Standardmäßig auf dem Ziel erstellt, lassen sich über einen passenden Parameter aber auch in anderen, lokalen Ordnern ablegen. Der komplette Befehl lautet dann z.B.

rsync --temp-dir=/tmp/rsync --no-owner --no-group -avP /mnt/backup/staging/ /mnt/backup/ftp/

So werden nur noch die wirklichen Zieldaten auf dem FTP-Server abgelegt und die Kopie scheint zuverlässig zu funktionieren. Alles nicht sonderlich schön, aber immerhin funktioniert das Konstrukt und eine weitere Kopie liegt irgendwo rum. Man könnte natürlich auch einfach NFS/iSCSI/… anbieten, aber das wäre ja moderne Technik…