Geschwindigkeitsoptimierung von duplicity

Geschwindigkeitsoptimierung von duplicity

duplicity und dessen Frontend duply sind eine weit verbreitete Backuplösungen aus der Linux-Welt. Obwohl beide Lösungen als absolut zuverlässig angesehen werden und mit einem großen Funktionsumfang punkten, werden beide Lösungen immer wieder aufgrund der langsamen Geschwindigkeit kritisiert. Neuartige Lösungen wie Restic, Attic oder Duplicacy scheinen hier deutlich schneller zu arbeiten, sind aber bei weitem nicht so flexibel einsetzbar und so weit verbreitet. Zeit für uns die Geschwindigkeit von duplicity genauer unter die Lupe zu nehmen und zu prüfen, ob man die Geschwindigkeit nicht optimieren kann.

Die Technik hinter den Lösungen duplicity und duply haben wir bereits in dem Artikel duplicity/duply: Datensicherung auf die Verlass ist vorgestellt. In diesem Artikel soll geht es rein nur die Möglichkeiten der Optimierung der Geschwindigkeit. Dies ist auch dringend notwendig, denn in Zeiten von Terabyte Festplatten kann es durchaus vorkommen, dass ein Vollback oder dessen Restore viele Stunden, wenn nicht sogar Tage läuft. Jede Verbesserung der Datenspeicherung kann große Auswirkungen auf die Laufzeit des Backups haben.

Diese Parameter haben wir getestet

Obwohl duplicity vielfältige Konfigurationsoptionen mitbringt, sehen wir nur vier wirkliche Ansatzpunkte für eine mögliche Optimierung. Diese sind:

  1. Datenübertragungsrate
  2. Größe der Volumes
  3. Verschlüsselung
  4. Kompression

Mit der Datenübertragungsrate ist die maximale Bandbreite zwischen der Backupquelle und dem Backupziel gemeint. Hier gibt es wenig zu optimieren, solange diese nicht den Flaschenhals darstellt. Wenn man ein lokales Backup auf eine USB-Festplatte macht, sollte man sicherstellen, dass es sich um eine USB 3.0-Festplatte handelt und diese an einen USB 3.0-Anschluß angesteckt ist. Wenn man eine Sicherung auf einen Cloud-Speicher schreibt, sollte man dies nicht über eine schwache Datenleitung probieren, sondern dafür sorgen, dass die Leitungskapazität ausreichend ist. Sollte tagsüber die Datenleitung durch andere Nutzer ausgelastet sein, empfiehlt sich die Speicherung in der Nacht.

duplicity speichert die Backup-Daten nicht in einer großen Datei, sondern teilt diese in einzelne kleine Dateien. Mit VOLSIZE kann man genau diese Größe der Volumes in Megabyte festlegen. Der Vorteil von kleinen Dateien besteht darin, dass bei einer fehlerhaften Übertragung oder einer Unterbrechung nicht so viele Daten erneut hochgeladen werden müssen, wobei dieser Vorteile mit einer längeren Laufzeit bestraft wird.

duplicity/duply verschlüsseln mit Hilfe von GPG die Backupdaten vor der Übertragung. Diese Verschlüsselung lässt sich mit –disable-encryption deaktivieren, was natürlich die Laufzeit verkürzen sollte. Dies sollte man aber nur in Betracht ziehen, wenn man das Backupziel vollständig unter Kontrolle hat.

Weiterhin werden die Backup-Volumes mit Hilfe von GZip komprimiert bevor diese gespeichert werden. Diese Kompression spart Speicherplatz auf dem Backupziel, verzögert aber natürlich die Laufzeit des Backups. Diese Funktion lässt sich mit –no-compression deaktivieren.

Im Folgenden werden wir die Datenübertragungsrate nicht weiter berücksichtigen. Trotzdem wollten wir aber wissen, welche Auswirkungen die verbleibenden drei Parameter auf die Laufzeit eines Backups und eines Restores haben.

Die Testergebnisse

Folgende Ergebnisse haben wir mit einem 2 GB großen Datenverzeichnis gemessen. Die Ergebnisse erheben keinen Anspruch auf absolute Genauigkeit, aber man erkennt, deutliche Tendenzen. Im Folgenden die Laufzeiten für das

Laufzeit / Restorezeit des Backups 1 MB Volsize 200 MB Volsize 400 MB Volsize
+ Enc. / + Comp. 178 / 129 s. 142 / 102 s. 139 / 96 s.
– Enc. / + Comp. 156 / 55 s. 131 / 39 s. 125 / 39 s.
+ Enc. / – Comp. 136 / 48 s. 114 / 35 s. 116 / 33 s.
– End. / – Comp. 59 / 36 s. 43 / 26 s. 43 / 25 s.

Welche Optimierungen lohnen sich

Wie nicht anders zu erwarten, reduziert sich die Laufzeit von Backup und Restore durch größere Volumes. Gleichzeitig scheinen sich ab einer gewissen Größe die Auswirkungen zu reduzieren. Unsere Empfehlung ist daher den Standardwert von 200 Megabyte pro Volume nicht zu verändern.

Deutlich spannender ist die Deaktivierung der Kompression, was einen Geschwindigkeitsvorteil von ca. 20 % bringt. Mit aktivierter Kompression lag die Backupgröße bei ca. 1.9 GB während ohne Kompression das Backupvolumen sogar auf 2.1 GB angewachsen ist und somit dank des Overheads größer als die zu sichernden Dateien geworden ist. Die geringen Einsparungen der Kompression können darin begründet liegen, dass wir mehrere größe ISO-Dateien gesichert haben, die wahrscheinlich keine großen Kompressionen mehr zugelassen haben. Wenn man über einen ausreichend großen Backupspeicher verfügt oder dieser nicht sehr teuer ist, lohnt es sich darüber nachzudenken, die Kompression zu deaktivieren.

Erstaunlicherweise hat die Deaktivierung der Verschlüsselung weniger Geschwindigkeitsvorteile gebracht als eine Deaktivierung der Kompression. Trotzdem beschleunigen sich Backup und Restore um ca. 10-15%. Sollte man sein Backup z.B. auf ein lokales NAS schreiben, kann sich eine Deaktivierung durchaus lohnen.

Am Interessantesten fanden wir die Tatsache, dass im Falle der Deaktivierung von Verschlüsselung und Kompression nicht 1+1=2 ergibt, sondern das Backup und der Restore nochmal deutlich schneller werden. Wenn beide Funktionen deaktiviert sind, benötigt man nur noch ca. 35 % der ursprünglichen Zeit. Das könnte bedeuten, dass ein Backup, was vorher länger als 24 Stunden lief, plötzlich in wenigen Stunden weggeschrieben ist.

Aufgrund dieser Ergebnisse haben wir es mit der Cockpit Version 1.4 möglich gemacht, die Kompression und die Verschlüsselung zu deaktivieren.

geschrieben von

Christoph Dyllick-Brenzinger

Christoph ist Gründer und Chefentwickler von datamate. Er ist ein absoluter Linux-Fan und hat schon früh seine Leidenschaft für Technik und Programmierung entdeckt. Seine langjährige Erfahrung als Unternehmensberater spürt man regelmäßig, wenn er nach optimalen Lösungen für die Kunden sucht. Wenn er nicht gerade den Tennisplatz unsicher macht oder bei Overwatch sein Liga-Ranking verbessert, verbringt Christoph seine Freizeit mit seiner Frau und seinen drei Kindern.