rsync Geschwindigkeit durch Teile und Herrsche

[PASST]

Hallo allerseits,
ich kämpfe seit Monaten mit der täglichen Sicherung unseres debian-basierenden Fileserver, den ich remote im LAN per rsync sichere. Über die letzten 1.5Jahren ist die Datenmenge von 850GB auf 1350GB angewachsen. Dabei ist die Sicherungsdauer von 9:30h auf über 23h im letzten Monat angewachsen. Per Zufall bin ich diese Woche auf die Idee gekommen, das data/shares-Verzeichnis nicht als ganzes zu sichern, sondern die Unterverzeichnisse einzeln zu sichern - Stichwort Teile und Herrsche. Damit ist auf einen Schlag die Sicherungsdauer zurück auf 9h gegangen.

Während der vorherigen Sicherungen des Gesamtverzeichnisses data/shares ist mir aufgefallen, dass rsync auf dem zu sichernden Fileserver nahezu 100% Leistung eines CPU-Kerns einnimmt. Das ist dann wohl die Erklärung der extrem langen Laufzeit.

Allerdings habe ich keine Erklärung warum rsync besser performed, wenn kleinere Unterverzeichnisse gesichert werden und nicht das große ganze Hauptverzeichnis. Kann mir jemand das erklären?

Gruß,
Peter

[uname]

Vollsicherung oder inkrementell? Selbst bei Vollsicherung kannst du inkrementell arbeiten. Parameter ist --link-dest

https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/

[schwedenmann]

Hallo


Ich glaube es hängt auch damit zusammen, das bei einer Vollsicherung aller Daten rsync erst eine Liste aller zu kopierender Daten anlegt

siehe dazu
https://linuxmuster.lbs.bw.schule.narki ... sehr-lange

und daraus

Das ist kein Wunder, rsync (bevor es kopiert), erstellt eine Liste aller
zu kopierenden Daten, und zwar aus dem Timestamp. Wenn du also zillionen
Dateien hast dauert das und verbrät ressourcen.

Bei einzelnen Verzeichnissen ist dann der Aufwand, CPU + AM nat. geringer und das kopieren läuft schneller ab.

mfg
schwedenmann

[uname]

Müsste man an den Logs sehen können.

[MSfree]

Über die letzten 1.5Jahren ist die Datenmenge von 850GB auf 1350GB angewachsen.

Ist der Datenbestand nun 1350GB? Oder ist die täglich zu übertragende Datenmenge 1350GB?

dass rsync auf dem zu sichernden Fileserver nahezu 100% Leistung eines CPU-Kerns einnimmt.

Kommandozeilenparameter?

Vor allem -c bzw. --checksum kann die CPU-Belastung in die Höhe treiben.

Eine etwas präzisere Problembeschreibung wäre hier durchaus sinnvoll

[PASST]

Es handelt sich um eine inkrementelle Sicherung und nachfolgend die Syntax für einen der Aufrufe:

Code: Alles auswählen

rsync -e "ssh -T -c arcfour -o Compression=no -x -p 22 -l ssh_Benutzer" -avRAX "FILESERVER:/data/shares/Unterverzeichnis" --numeric-ids --delete --exclude-from=Exclude_Verzeichnisse /mnt/Datensicherung/Thu/181025 --link-dest=/mnt/Datensicherung/Thu/last

Bei der inkrementellen Sicherung wird dann nur die zur letzten Sicherung unterschiedliche Datenmenge kopiert. Das waren bei einer letzten Sicherungen 30GB, kann aber auch deutlich weniger oder auch mehr sein.

[MSfree]

Das waren bei einer letzten Sicherungen 30GB, kann aber auch deutlich weniger oder auch mehr sein.

OK, daß die Datenmenge schwankt, ist klar. 30GB sind jedenfalls keine unüberwindbare Hürde.

30GB in 23h bedeutet eine Datenrate von rund 3MBit/s. Im LAN sollte deutlich mehr gehen, über DSL limitiert die langsamere Uplink-Geschwindigkeit der beiden beteiligten Anschlüße.

Was du mal prüfen solltest, ist, wo der Flaschenhals ist. Du läßt rsync über ssh laufen. Das ist zwar sicherer, aber in einem LAN nicht unbedingt nötig (wenn du dem LAN trauen kannst). top sollte während des Backuplaufs anzeigen, was die CPU wirklich belastet. Vor allem am Anfang wird auf Sender- und Empfängerseite eine Dateiliste erzeugt, die zur Differenzbildung benutzt wird. Dabei werden die Platten rekursiv durchsucht. Bei sehr vielen Dateien kann das eine Weile dauern, wie lange, kannst du mit einem find /Verzeichnisname simulieren. Für jede Datei wird eine Prüfsumme berechnet, die ebenfalls als Merkmal für die Differenzbildung verwendet wird, was ziemlich in die Rechnzeit gehen kann.

Wenn die ersten Dateien übertragen werden, sieht man das an der Ausgabe im Terminalfenster, wenn man rsync mit -v startet. Ab dem Zeitpunkt spielt fast nur noch die Netzwerkgeschwindigkeit eine Rolle und die Geschwindigkeit mit der ssh ver- und entschlüsseln kann.

[PASST]

Der Fileserver ist eine VM und die Sicherung wird vom VM-Host ausgeführt. Ich vermute, das Erzeugen der Dateiliste bei einem entsprechend groß gewählten Quell-Verzeichnis wird den rsync Prozess auf dem Server überlasten. rsync wird dann in top auch dauerhaft mit fast 100% angezeigt. Bei kleineren Quell-Verzeichnissen gibt es dieses Problem nicht.

Kann man dieses Verhalten denn in irgendeiner Form berechnen bzw vorhersagen?

[weshalb]

Ich hege ebenfalls gerade die Überlegung, Rsync aufzuteilen. Es geht bei mir zwar nur um etwa 500GB, doch das dauert schon ziemlich lange und teilweise wird sogar der Inhalt von Ordnern vergessen.

[Stuttgarter]

und teilweise wird sogar der Inhalt von Ordnern vergessen.

Kannst Du das etwas näher erklären und/oder können andere Anwender das bestätigen? Hintergrund: Ich verlasse mich voll auf rsync!

[EDIT] Ich habe mir händig einige Verzeichnisse willkürlich heraus gepickt und sie via diff verglichen. Kann nur sagen, dass ich keinerlei Unstimmigkeiten feststellen konnte.
Mehrere TB Daten mittels diff zu vergleichen, steht allerdings der immense Zeitaufwand entgegen. Werde daher wohl ein kleines Script schreiben, das regelmäßig Verzeichnisse zufällig auswählt und dann diese vergleicht. 100% Sicherheit gibt es halt nunmal nicht. [/EDIT]