it-swarm.com.de

Beschleunigt die Komprimierungsoption -z mit rsync die Sicherung?

In rsync, -z komprimiert Dateidaten während der Übertragung.

Wenn ich richtig verstehe, -z Dateien vor der Übertragung komprimieren und nach der Übertragung dekomprimieren. Reduziert die Zeit während der Übertragung aufgrund von Komprimierung die Zeit für Komprimierung und Dekomprimierung?

Hängt die Antwort auf die Frage davon ab, ob ich über USB (2.0 oder 3.0) auf eine externe Festplatte oder über SSH über das Internet auf einen Server sichern kann?

46
Tim

Es ist eine allgemeine Frage. Verbessert die Komprimierung und Dekomprimierung an Endpunkten die effektive Bandbreite einer Verbindung?

Die effektive (wahrgenommene) Bandbreite einer Verbindung, die an Endpunkten Komprimierung und Dekomprimierung durchführt, ist eine Funktion von:

  1. wie schnell Sie komprimieren können (Ihre CPU-Geschwindigkeit)
  2. die tatsächliche Bandbreite Ihres Netzwerks

Die Funktion wird mit diesem 3D-Diagramm beschrieben, das Sie möglicherweise für Ihre spezielle Situation konsultieren möchten:

(enter image description here

Das Diagramm stammt aus dem Artikel Compression Tools Compared 2005 von http://www.linuxjournal.com/ .

55
PSkocik

Wenn Sie eine sehr langsame Verbindung haben (denken Sie an GPRS), möchten Sie Ihre Daten auf jeden Fall so weit wie möglich komprimieren, da sonst Ihre Verbindung die Daten verlangsamt.

Wenn Sie eine sehr langsame CPU und eine schnelle Verbindung haben (wie ein eingebettetes Netzwerkgerät), möchten Sie Ihre Daten normalerweise nicht komprimieren, da sonst Ihre CPU die Geschwindigkeit verlangsamt.

14
michas

Ja, die Geschwindigkeit der Verbindung bestimmt, ob die Geschwindigkeit zunimmt. Dies ist nur für die USB-Sicherung ein Overhead, da nicht die Festplatten die Daten aufblasen, sondern der Prozess, der die Daten schreibt. Dieselbe Maschine, die es liest und entleert, muss es auch aufblasen und schreiben. Rsync ist immer noch zwei Prozesse, aber Ihr Speicher, um Daten von einem Prozess zum anderen zu übertragen, ist schnell genug und die CPU benötigt mehr Zeit zum Komprimieren (während sie in denselben Speicher eingelesen wird, der sie später übergibt :).

Die Komprimierung hilft nur, wenn Sie einen Sender- und einen Empfänger-Rsync und ein langsameres Netzwerk dazwischen haben. 1 Gbit ist möglicherweise bereits schnell genug, wenn Sie eine lokale NAS, z. B. 10 Gbit ist bereits eine rohe SATA-Geschwindigkeit) haben. Daher ist eine Komprimierung nur erforderlich, wenn Sie über 100 Mbit oder weniger Konnektivität verfügen, und dies ist nur dann sinnvoll, wenn die komprimierte Daten sind komprimierbar.

Ich denke, rsync könnte bemerken, dass es nicht auf zwei Maschinen läuft, sondern auf einer und überspringt die Komprimierung, ist sich aber nicht sicher.

3

Hängt davon ab, wie komprimierbar Ihre Daten sind und wie viel Rechenleistung Ihre Quelle und Ihr Ziel haben. Meiner Erfahrung nach wird eine vollständige Festplattensicherung auf etwa 30-50% ihrer ursprünglichen Größe komprimiert, sodass es sich möglicherweise lohnt, sie einmal auszuprobieren. Ansonsten kümmern Sie sich nicht um die Komprimierung. Es kann sich lohnen, Ihre Komprimierungsrate mit pigz -c <your file> | wc -c Zu testen und die zurückgegebene Größe mit Ihrer Originalgröße zu vergleichen.

3
RAKK

tl; dr Über langsame Übertragungsverbindungen komprimieren, sonst nicht. Unten finden Sie einen Test zur Komprimierungsgeschwindigkeit, einen Link zu einem Bandbreitenkonvertierungstool und einige Informationen.

Die Verwendung der Komprimierung mit rsync beschleunigt die Arbeit nur, wenn die Zwischenverbindung "langsam genug" ist, d. H. Wenn die Maschine an einem Ende einen komprimierten Datenstrom schnell genug erzeugen kann, um die Kommunikationsverbindung zu sättigen.

Also, was ist der langsamste Link, bei dem ich die Komprimierung verwenden sollte, um etwas zu gewinnen?

Das Folgende ist ein sehr unwissenschaftlicher Test, der zeigt, wie schnell gzip Daten erzeugen kann und was dies bedeutet, ob Sie Ihre Netzwerk-Massenübertragungen im Allgemeinen komprimieren sollten.

Die Eingabedaten ändern das Testergebnis erheblich . Ich verwende eine unkomprimierte (!) Normale Datei auf meinem Computer, die möglicherweise für die Art von Daten repräsentativ ist, die ich normalerweise über Netzwerke übertrage. Die Verwendung von /dev/zero (Erzeugung unbegrenzter Nullen) wäre irreführend, da ein Strom von Nullen sehr einfach zu komprimieren wäre, und die Verwendung von /dev/random Wäre aus dem entgegengesetzten Grund irreführend. Also verwende ich stattdessen eine TAR-Datei aus meinem $HOME/local - Verzeichnis, die Software enthält, die ich in meinem $HOME Installiert habe. Die Datei ist an sich unkomprimiert, enthält jedoch eine Mischung aus Binärdateien, kleinen komprimierten Dateien und Quell-/Textdateien. Würde ich sie mit der Standardeinstellung für gzip komprimieren, würde sie um 67% von 64 MiB auf 22 schrumpfen MiB.

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

Ich mache das ein paar Mal, um ein Gefühl dafür zu bekommen, was der Durchschnitt sein könnte, und es kommt auf ungefähr 7800000 Bytes/s.

Dann benutze ich einen Netzwerkbandbreitenrechner , um zu sehen, in was dies konvertiert. In diesem speziellen Fall ist die Kabelverbindung "100 MB Ethernet" knapp unter der Kapazität einer Internetverbindung mit "VDSL-Download", etwas schneller als eine drahtlose Verbindung "802.11 [a/g]" und irgendwo zwischen "Bluetooth v3.0" (langsamer) und "USB 2.0" (schneller).

Dies bedeutet, dass wenn ich die Komprimierung für etwas schnelleres verwende, die Komprimierung wahrscheinlich die Übertragung der Datei verlangsamt .

rsync verwendet möglicherweise nicht die genau gleichen Bibliotheken wie gzip, um die Komprimierung durchzuführen, aber das Obige würde Ihnen zumindest einen kleinen Hinweis geben .

rsync macht jedoch mehr als nur Komprimierung, wie Sie wissen, und die reale Geschwindigkeitssteigerung ergibt sich nur aus der Übertragung von [Bits von] Dateien, die sich geändert haben.

Nach meiner eigenen Erfahrung ist die Verwendung der Komprimierung mit rsync in den letzten 10 Jahren immer weniger vorteilhaft geworden, da die Bandbreite der Netzwerke zugenommen hat (wo ich mich befinde).

Für inkrementelle Sicherungen würde ich definitiv empfehlen, die Option --link-dest Zu untersuchen (dies hat nichts mit der Übertragung zu tun, sondern nur damit, wie die Dinge auf dem Ziel gespeichert werden). Wenn Sie dies über SSH tun, verwenden Sie aus den gleichen Gründen wie oben keine Komprimierung, wenn Ihre SSH-Verbindung bereits komprimiert ist, und komprimieren Sie nur SSH-Verbindungen (Tunnel usw.), die über langsame Verbindungen erfolgen.

1
Kusalananda