Schlagwort-Archive: Backup

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.

dd-Backupfortschritt mit pv visualisieren

Vollsicherungen gesamter Festplatten oder Partitionen lassen sich mit dem Unix-Tool „dd“ schnell und einfach anfertigen. Während das Tool automatisiert wohl keine Wünsche offen lässt ist es ein wahrer Quählgeist, wenn man dringend auf die Fertigstellung eines Jobs wartet, denn eine automatische Ausgabe des Fortschirttes ist nicht vorgesehen. Zwar kann man sich hier behelfen, in dem man über den „kill„-Befehl das Signal „SIGUSR1“ an den Prozess sendet und so die Anzeige der verarbeiteten Datenmenge erzwingt, wirklich komfortabel ist dies jedoch nicht.

Senden von SIGUSR1

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv1-300×98.png
Um das Signal SIGUSR1 an einen Prozess zu senden sollte im ersten Schritt dessen Prozess-ID (PID) ermittelt werden, hierzu kann man in der Ausgabe „ps“ nach dem zuvor gestarteten „dd„-Befehl suchen. Ich nutze zur Suche im Beispiel „grep„. Da zum Zeitpunkt des Schreenshots mehrere „dd„-Prozesse liefen suche ich zudem nach der Quelle des Testjobs (urandom).

kronos ~ # ps xa | grep "dd" | grep urandom
23204 pts/24   R+     0:24 dd if=/dev/urandom of=/dev/zero

Mit dieser ID kann man nun das Signal über den Befehl „kill“ absetzen. „dd“ verarbeitetet dieses Signal intern, das Programm wird hierdurch nicht beendet.

kronos ~ # kill -SIGUSR1 23204

Während auf der aktuellen Konsole keine Ausgabe erfolgt müsste dd nun einen Status ausgeben, welcher u.A. die verarbeitete Datenmenge sowie die Geschwindigkeit enthält:

162183+0 Datensätze ein
162182+0 Datensätze aus
83037184 Bytes (83 MB) kopiert, 37,7423 s, 2,2 MB/s

 

Wer sich einen übersichtlicheren und automatisierten Status wünscht kann hier mit dem Zusatztool „pv“ (Pipe Viewer) nachhelfen. Statt die Daten direkt von „dd“ an das Ziel schreiben zu lassen werden sie durch „pv“ geleitet, welches wiederum eine statistische Auswertung anzeigt. Als Ziel kann dann über einen weiteren „dd„-Prozess wieder eine Datei oder Gerät verwendet werden, alternativ gehen natürlich auch Kompressionstools wie „gzip“ oder man lässt die Daten z.B. mittels „nc“ (netcat) oder „SSH“ (Secure Shell) zur Speicherung an einen anderem Rechner senden.

Beispiele mit „pv

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/11/pv2.png

Daten in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | dd of=vm-102-disk-1.img
  15GiB 0:20:34 [  19MiB/s] [12,5MiB/s] [============================================>                                                      ] 46% ETA 0:23:12

Daten über gzip komprimieren und in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip > vm-102-disk-1.img.gz
  15GiB 0:20:34 [  19MiB/s] [12,5MiB/s] [============================================>                                                      ] 46% ETA 0:23:12

Daten über gzip komprimieren, per SSH mit schwacher Verschlüsselung an einen anderen Rechner senden und dort in Datei speichern

dd if=/dev/lvm/vm-102-disk-1 | pv -pterabs 32g | gzip | ssh -c arcfour,blowfish-cbc backup@cautio.lan.adlerweb.info 'dd of=/var/backup/vm-102-disk-1.img.gz'
Password:
 251MiB 0:00:23 [12,6MiB/s] [10,8MiB/s] [>                                                                                                  ]  0% ETA 0:49:38

 

Wichtig hierbei ist, dass „pv“ am Ende die Größe der Quelldatei/des Quellgerätes genannt wird, in diesem Fall 32 GB. Ingesamt bedeuten die Optionen folgendes:

-p Fortschrittsbalken anzeigen
-t Bisher vergangene Zeit anzeigen
-e ETA, also erwartete Restzeit, anzeigen
-r Aktuelle Datenrate, also „Geschwindigkeit“, anzeigen
-a Durchschnittliche Datenrate anzeigen
-b Bereits kopierte Datenmenge anzeigen
-s Größe der Quelle in Byte, k,m,g,… möglich

Alternative Reihenfolge zum besseren Merken: pertabs (per tabs) oder für Nutzer diverser Imageboards betraps.

Die Ausgabe ist wie folgt zu lesen:

  15GiB        0:20:34  [  19MiB/s] [12,5MiB/s] [======      ] 46% ETA 0:23:12
Kop.Datenmenge|Verg.Zeit|Datenrate|Ø Datenrate | Fortschritt      |Restzeit

Damit wäre der nervöse Admin mit beruhigenden Statistiken versorgt und weiß wie lange er sich noch gedulden muss – eine Ausrede weniger die Backups zu vernachlässigen. Natürlich kann „pv“ auch für andere Konstrukte verwendet werden, welche mit einer Pipe arbeiten.