Wie Backups mit Hardlinks schnell umziehen?

[Claus67]

Hallo,
ich will meine monatlichen ~120 Backups mit Hardlinks von einer DS112 mit 2TB auf eine DS214+ 4TB umziehen, da die 2TB Platte praktisch voll ist.
Damit die Hardlinks (-H) erhalten bleiben verwende ich auf der DS214+ rsync zum Kopieren sowie eine checksummenprüfung (-c):

rsync -aHXcv --numeric-ids --itemize-changes --delete --exclude=#recycle/ --log-file=<.....>/rsync.log root@192.168.0.112:/volume1/backups/snapshots/ /volume1/backups/snapshots/

Nun habe ich testweise nur eines der Backups (monthly.120, 900GB) kopiert und bin ganz überrascht, dass ich auf eine durchschnittliche Übertragungsrate von 3,2 MB/Sekunde komme...
Nun überrascht mich die geringe Übertragungsrate im vergleich zu 2016 als ich das mit ~70 Backups schon mal gemacht hatte:
- Beim letzten Umzug 2016 lag die Übertragungsrate bei 7-9 MB. Die "backups"-Ordner sind damals wie heute verschlüsselt.
- Anhand der rsync log-files von damals und heute sehe ich, dass rsync 2025 erst nach 16 Stunden startet die erste Datei zu kopieren, damals sofort.
- Schaue ich mir im DSM der DS214+ und DS112 den Ressourcen-Monitor an, erreicht die CPU der DS112 ~80% Auslastung mit SSH bei ~30-40%, DS214+ bzw. CPU weit darunter.
Die DS112 und DS214+ sind zwar beides "alte Schätzchen" aber sind 3,2 MB/s wirklich normal?

Irgendeine Idee wie ich die Übertragungsrate beschleunigen kann?

Die checksummen-Prüfung möchte ich gerne beibehalten.

Danke
Claus

 

[Hagen2000]

Durch Angabe der Option -c erzwingst Du dass rsync auf beiden Seiten bei allen vorhandenen Dateien die Prüfsumme berechnet und bei identischer Prüfsumme das Kopieren überspringt. Hast Du viele vorhandene Dateien, benötigst Du also auf beiden Seiten vor allem CPU-Leistung für die Prüfsummenberechnung. Die sehr hohe CPU-Auslastung auf dem älteren System passt also ins Bild.
Ohne die Option -c werden im Wesentlichen Dateiattribute wie Größe und letztes Änderungsdatum überprüft, das sollte wesentlich schneller geschehen.
Wie hast Du die Datenübertragungsrate ermittelt?

 

[Hagen2000]

Hier ist ein interessanter Artikel, der die Funktionsweise von rsync im Detail beschreibt: https://rsync.samba.org/how-rsync-works.html
Du könntest auch mal die Option -W (—-whole-file) probieren, dass könnte in deinem Fall helfen (in Kombination mit/ohne Option -c).

 

[Claus67]

Hallo Hagen2000,
Danke für den Artikel. Der was sehr aufschlussreich.

Nach weiterem Google und ChatGPT bin ich auf den rsync daemon umgestiegen, da dort kein SSH, der die Verbindung verschlüsselt und Performance frisst, verwendet wird. Da ich im eigenen Netzwerk bin sollte das OK sein.

Ich habe auch die Checksummen-Prüfung -c rausgenommen. Die sollte beim allerersten Kopieren der vollen auf das leere Backup-NAS nichts bringen, da auf dem neuen NAS ja noch keine Dateien vorhanden sind.
Auch dachte ich fälschlich, die checkummen-Option wäre ein VERIFY d.h., dass die geschriebene Datei nochmal zurückgelesen und verglichen wird um Schreibfehler zu vermeiden. Auf der rsync man-Page heißt es stattdessen, dass anhand der checksummen von Quelle und Ziel entschieden wird, ob die Datei bzw. Blöcke übertragen werden.

Die Option -W (--wohle-file) sollte auch bei einem leeren Ziel-NAS noch nichts bringen da alle Dateien sowieso insgesamt übertragen werden müssen.

Interessant wird -c und -w wenn ich meiner Paranoia folge und den rsync ein zweites mal aufrufe um Schreibfehler zu erkennen. Dann sollte das Log-file leer bleiben, als keine Dateien übertragen werden, da diese ja auf dem Quell- und Ziel-NAS identisch sein sollten.

Was die Dateiübertragungsrate angeht hatte ich den rsync nur auf einen einzigen Backup-snapshot von 900GB und NICHT auf alle 120 hardverlinkte snapshots, die ich kopieren will, laufen lassen. Das dauerte schon 3,6 Tage....
Die Dateiübrtagungsrate, übertragene Bytes insgesamt, usw. gibt rsync am Ende selbst aus. Möglicherweise auch nur weil ich -v (verbose) gewählt hatte. Das war dann aber auch mit der über die via "du" ermittelte Gesamtgröße und wie lange der rsync gedauert hat konsistent.

Was die Kopie der 120 hardverlinkten Backup-snapshots angeht so hoffe ich bzw. habe ich auf ChatGPT gelesen, dass rsync sich die inodes der Hardverlinkungen merkt und dann die doppelten Dateien nicht mehr überträgt.
Nichts desto trotz muss er die 120 Verzeichnisbäume durchgehen und aufbauen.

Ich habe den rsync nun mit

/bin/rsync -aHXv --numeric-ids --itemize-changes --delete --password-file=/root/.rsync_passwd --exclude=#recycle/ --log-file=/volume1/homes/admin/migration/rsync_DS112_DS214p_251012_1719.log /volume1/backups/snapshots/ rsync://backup@192.168.0.214/Migration/

gestartet. Beim letzten mal 2016 dauerten ~70 hardverlinkte snapshot-Verzeichnisse von einer DS112 auf eine DS213+ so 2-3 Wochen zum kopieren.
Ich bin gespannt, was bei 120 Verzeichnissen rauskomme.... ;-)

 

[Hagen2000]

… SSH, der die Verbindung verschlüsselt und Performance frisst …

Bei modernen CPUs fällt das nicht sehr ins Gewicht. Ich hatte dazu selbst erst kürzlich Tests durchgeführt und das war bei mir kaum messbar. Ich denke, dass die vielen I/O-Operationen auf den Festplatten der eigentliche Flaschenhals sind. Bin jedenfalls gespannt auf deine Ergebnisse.

 

[Claus67]

Nach dem herausnehmen der Checksummen-Option -c zeigt rsyn ein anderes Verhalten.

Trotz des rsync von 120 hardverlinkten Verzeichnis war die "building file list" nach 8 Sekunden abgeschlossen und die Dateiübertragung begann, wo bei einem einzigen harverlinkten snapshot-Verzeichnis mit Checksum-Option diese hingegen 16 Stunden dauerte....
rsync hat zudem die oberste Verzeichnisebene alle 120 snapshots angelegt und begonnen den ersten zu füllen.

Was SSH angeht lagt die CPU-Auslastung bei 25% laut "top", wie auch von rsync.

Nun unter Verwendung des rsync-Daemon ohne SSH, lastet der rsync client wie server-Seite die CPU zu 25% aus, sodass sich laut DSM eine durchschnittliche CPU Auslastung von so 60%.
Was die Übertragungsrate angeht liegt diese laut DSM grob doppelz so jdo bei 7,7 MB/s.

Was mich wundert, dass rsync die freie Kapazität von CPU und Netzwerk nicht weiter nutzt....

Soweit erstmal für's erste. Mal sehen wie sich das hier weiterentwickelt.......