Schlagwort-Archive: Borg Backup

rsync vs. curlftpfs: mkstemp-Fehler

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…

BitBastelei #193 – Backups unter Linux » Borg Backup

BitBastelei #193 - Backups unter Linux » Borg Backup

(48 MB) 00:36:23

2016-04-17 10:00 🛈

Existiert kein Backup, sind die Daten nicht wichtig

Diese Aussage ist schön provozierend, treibt gerne Leute in meiner Umgebung zur Weißglut, hat aber einen wichtigen Kern: Wer seine Daten benötigt sollte Datensicherungen haben. Während ich bei den lokalen Servern eine gut funktionierende und getestete Infrastruktur habe liegen mir externe Dienste etwas im Magen. Auf allen Systemen habe ich direkten Zugriff, die Daten sollen übers Netz auf ein Zielsystem gesichert werden. Die Übertragung muss verschlüsselt erfolgen, als zusätzliche Hürde ist die Bandbreite recht gering: Je nach Last kann diese schon mal auf wenige MBit/s sinken oder gar ganz abbrechen. Weiterhin benötige ich schnellen Zugriff auf einzelne Dateien der Sicherung und die Möglichkeit auch ältere Revisionen einer Datei zu erhalten. Hier setzte ich lange Zeit auf rdiff-backup.

Videoinhalt

  • 01:06 Meine Anforderungen
  • 02:51 rdiff-backup // Wie lief mein Backup bisher?
  • 05:10 OwnCloud/BTSync/Sparkleshare
  • 06:33 Unison
  • 07:36 Obnam
  • 10:18 BORG › Was ist BORG?
  • 12:42 BORG › Geschichte
  • 13:39 BORG › Aufbau & Code
  • 14:32 BORG › Sicherheit
  • 15:47 BORG › Kompression
  • 17:39 BORG › Deduplizierung
  • 19:45 BORG › DEMO
  • 33:28 BORG › EOT

rdiff-backup

Das Programm arbeitet über eine SSH-Verbindung und kann nahezu alle unter Linux auftretenden Dateitypen verarbeiten. Auch ACL & Co. ist üblicherweise kein Problem. Wie der Name schon andeutet werden bei bestehenden Dateien nur Änderungen übertragen. Auf dem Zielsystem findet sich nach dem Backup der letzte Stand direkt zugreifbar im Dateisystem – perfekt wenn man nur eine gelöschte Datei schnell zurückspielen muss. Ältere Versionen (bzw. die Differenzen) werden in einem zusätzlichen Ordner gespeichert, über die Software lassen sich ältere Versionen der Dateien dann rekonstruieren.

Eigentlich war ich recht zufrieden mit diesem System. Backupfehler traten nur selten auf, der Restore war einfach und der Ressourcenverbrauch überschauber. Nicht ganz so prickelnd: Die Software, welche auf Python 2 (ja, nicht 3) basiert, hat seit 2009 kein Update mehr gesehen. Zum einen ein Problem wegen der nur schwer noch zu installierenden Python-Version, zum Andern gibt es Gerüchte über mögliche Datenverluste. Auch bei mir hat es zuletzt durch Netzabbrüche das Repository zerlegt, sodass ich mich auf die Suche nach Alternativen machte.

Owncloud, Sparkleshare, BTSync & Co

…sind auf Desktop-Systemen schöne Systeme, für Datensicherungen aber eher wenig geeignet. Zwar gibt es die Möglichkeit auf ältere Versionen zugreifen zu können, die Archivverwaltung ist aber meist nicht sehr flexibel. Auch die Unterstützung erweiterter Attribute ist prinzipbedingt meist nicht gegeben. Größtes Problem für mein Vorhaben: Mit großen Datenmengen kommen solche Programme nicht wirklich klar.

Unison

Unison fällt in etwa in die selbe Kategorie, schien aber besser optimiert. Leider zeigt sich die Revisionsverwaltung für meine Zwecke etwas unflexibel. Auch die genutzte Programmiersprache OCaml ist nicht unbedingt etwas, was für mich leicht anpassbar aussieht. Zuletzt ist auch hier die Unterstützung von Metadaten unter Linux noch ausbaufähig.

Obnam

…wird bei vielen als „Drop-In-Replacement“ beworben. Die Funktionen ähneln rdiff-backup, jedoch wird zusätzlich eine Deduplizierung und Verschlüsselung unterstützt. Die Software muss nur auf einem System installiert werden, am Ziel werden „Chunks“ abgelegt, ein direkter Zugriff auf Dateien ist entsprechend nicht mehr möglich.

Bei mir wollte die Software nicht sonderlich mitspielen – Backups dauerten ewig, Verbindungsabbrüche führten zu verwaisten Locks und Mangels brauchbarem Verbose-Mode ist nur schwer zu ermitteln was genau die Software aktuell überhaupt versucht zo erledigen.

(Wir sind die) Borg

Der Funktionsumfang von BorgBackup ist Ähnlich zu Obnam: Deduplizierung, Kompression, Verschlüsselung und Co. Der Fork der Software Attic hat vor kurzem die Version 1.0.0 erreicht. Hier ist der direkte Zugriff nicht über ein FUSE-Modul möglich. Mit Ausnahme von dateisystemspezifischen Attributen werden ACLs und Xattr samt den meisten Device-Files und FIFOs mitgesichert.

Erster Eindruck: Scheint recht sauber zu laufen, das Projekt sieht gut dokumentiert aus. Die Optionen erlauben es alle Dateien und laufenden Abläufe auf der Konsole anzuzeigen – gerade bei meiner Konstellation sehr praktisch, da ich so direkt sehe ob überhaupt noch etwas passiert. Obendrein kann man auch gleich die Effizienz von Kompression und Deduplizierung schon während des Backups sehen. Die fehlende Konfigurationsdatei lässt sich über passende Shellscripte kompensieren, führt auf meinem 1080p-Monitor allerdings auch zu einem 4-zeiligen Progammaufruf. Der 200GB-Datensatz eines meiner Server mit 10 Revisionen passt auf etwa 75GB. Minuspunkte gibt es für die Tatsache, dass das Grundsystem (mit Ausnahme von Kompression/Deduplizierung) nicht mit mehreren Threads klar kommt. Gerade bei großen Repositories führt das doch zu der ein oder anderen Wartezeit.

Momentan sieht BORG als vielversprechendste Lösung aus, bietet es doch den größten Funktionsumfang, eine aktive Weiterentwicklung und bisher keine nennenswerten Programmfehler. Sicher nicht so ausgearbeitet wie große Lösungen wie Amanda oder Bacula, für die meisten Anwendungen aber ausreichend und wesentlich einfacher einzurichten.