Datenbackup extrem langsam bei Firefox- und Thunderbird-Profilen

[FatManStanding]

tach,

ich mache von meinem ubuntu aus regelmäßig backups auf einen älteren rechner hier im lan. beide sind über GB-LAN an die fritzbox 7490 angeschlossen (green mode ist deaktiviert). als backup-tool nutze ich freefilesync. "normale" backups (also alles außer besagter profil-ordner) geht mit normaler geschwindigkeit. die anzeigen von freefilesync schwanken etwas, liegen aber um die 50-120MB/sec. wenn ich aber die profil-ordner sichere (firefox ca. 1,9gb, thunderbird ca. 1,1gb) dauert das stunden. übertragungsraten oft unter 100KB/sec. firefox und thunderbird laufen nicht. die profil-ordner befinden sich in einer extra partition auf einer ssd (von der aber nicht gebootet wird), die anderen dateien auf einer festplatte. das backup wird auf den backup-server auf die gleiche festplatte gespeichert. wieso ist das da so langsam? liegt das daran, dass das oft viele kleine dateien sind? das erkärt wohl aber nicht diesen EXTREMEN unterschied.

das gleiche passiert im übrigen auch wenn manuell die daten kopiere mit cp oder rsync (ich vermute freefilesync nutzt im hintergrund auch rsync). irgendwas ist an den profil-ordnern anders.

 

[Sje2006]

Die Profile von Firefox und Thunderbird bestehen aus vielen kleinen Dateien und solche kleinen Dateien verlangsamen das kopieren von Daten.

 

[SSD960]

Hast du an den Cache gedacht. Hunderte kleine Dateien. Ich habe die Caches der Browser alle verschoben....Das sogar in eine Ramdisk die beim Starten, des PCs, gelöscht werden.

 

[whats4]

es sind unzählige und winzige dateien....
cache sichern kannst dir sparen, ned sinnvoll

 

[Uridium]

Welcher i/o scheduler? Bei traditionelle HDDs kann BFQ helfen.
Edit: Wobei... wenn Samba im Spiel ist, wird es eher am Netztransfer liegen. Man könnte versuchen es zu tunen (rsize, etc), besser aber wäre es, wenn Du die Daten auf der Serverseite (nur für den Transfer) komprimierst. Samba mag kleine Dateien nicht. Alternativ könnte auch NFS (statt smb) helfen.

Edit:
Beispiel (packen->transfer->entpacken):
tar -C /srcbackupfolder . -cf - |pigz |ssh root@192.168.1.1 -- "tar xzf - -C /dstfolder"

Edit2:
rsync kann das wohl auch direkt:
https://unix.stackexchange.com/questions/188737/does-compression-option-z-with-rsync-speed-up-backup

 

[SSD960]

Glaube das er das nicht möchte. Einfach den Cache beim Kopieren auslassen...

 

[Piktogramm]

wieso ist das da so langsam? liegt das daran, dass das oft viele kleine dateien sind? das erkärt wohl aber nicht diesen EXTREMEN unterschied.

das gleiche passiert im übrigen auch wenn manuell die daten kopiere mit cp oder rsync (ich vermute freefilesync nutzt im hintergrund auch rsync). irgendwas ist an den profil-ordnern anders.

Es kommt etwas drauf an, was du genau machst. Also sowohl ob du nur kopierst oder Backups mit Generationen anlegst als auch das verwendete Protokoll zur Übertragung. Generell ist es aber so, dass für jede Datei mehrere I/O Zugriffe auf Quelle und Ziel notwendig sind, bevor eine Übertragung abgeschlossen werden kann. Jeder I/O Zugriff über Netzwerk bedingt, dass die komplette Roundtriptime (RTT bzw. die Latenz die das Programm "ping" ausspuckt )mit Warten zugebracht wird. Angenommen es benötigt 4 I/O Zugriffe je Datei und du hast ein RTT von 20ms. Für jede einzelne Datei gehen also 80ms mit reinem Wartevorgang flöten. In 80ms könnte eine 1GBe Leitung ~9,5MB übertragen. Wenn die Nutzlast nur 1MB groß ist, dann braucht es auf der selben 1GBe Leitung nur 8,3ms zum Übertragen der eigentlichen Nutzdaten.

Im Endeffekt bleibt 8,3/80 = 0,10 etwa 10% der maximalen Übertragungsrate übrig, schlicht weil ein Großteil der Zeit auf Netzwerk I/O gewartet wird.

Wie bereits gesagt wurde, ist es sinnvoll erstmal alle unnötigen Daten auszuschließen, also Caches. Die liegen aber eigentlich eh unter ~/.cache/mozilla/ und den Ordner kann man nun wirklich simpel ignorieren. Was die Ordner von Thunderbird und Firefox aufbläht sind wirklich Nutzdaten[1].

Eine weitere Maßnahme wäre das Verwenden von tar-files. Also die Profilordner als tar verpacken und dann zur Senke übertragen.

Oder man bastelt sich Parallelisierung selber zum Beispiel wie es RedHat als Beispiel hat:
https://access.redhat.com/solutions/5652631
oder mit GNU parallel

Oder, langweilig, aber das im besten Sinne mit vorta bzw. Borg Backup den Spaß einfach Automatisieren. Zum einen weil Vorta I/O Overhead umgeht und weil es als automatisierter Hintergrundprozess einem fast egal sein kann, wie lang es dauert.


[1] Kann man drüber Streiten, muss aber viel Zeit investieren um da zu optimieren und dennoch funktionstüchtige Backups ziehen zu können.