Rsync vs sftp

Ich synche schon seit 15 Jahren mit rsync serverseitige Backups.. ich 
weiß schon wie es funktioniert.

Wenn ich eine 1Gigabyte Datei mit  "rsync avh ./1GB.img 
root@192.168.0.101:/media/3TBnvme/"

Ca. 40-50MB/s

Dann ist es doch egal wie ich es mache.


sftp root@192.168.0.101:/media/3TBnvme/
>put 1GB.img

über 100MB/s

Also die Daten brauchen auch online zum Backupserver mit rsync einige 
Stunden bei 10MB/s.. das ist dann aber normal.

Wenn ich eine 1Gigabyte Datei mit  "rsync avh ./1GB.img
root@192.168.0.101:/media/3TBnvme/"

Ca. 40-50MB/s

bei einer Datei probiere mal

-W, --whole-file            copy files whole (w/o delta-xfer algorithm)

---


rsync hatte o. hat ein Problem mit wirklich großen Dateien. (2007)
 https://www.mail-archive.com/rsync@lists.samba.org/msg17812.html

Ein T. schrieb:
> Wirklich?

Naja, ich synche halt einfach..

it doesn't matter schrieb:
> rsync hatte o. hat ein Problem mit wirklich großen Dateien.

Okay, danke.

Ich dachte halt nur das es lokal richtig abgeht bei 1/2,5gbit Uplink 
zwischen SSD und nvme.. scheint beim erstsync halt doch länger zu 
dauern. Das sind locker 500gb an Dateien kleiner 1mb. Vielleicht ist das 
nur der Overhead.

Ich schiebe die Dateien eigentlich nur unter storage und 
Produktivservern.. wollte jetzt aber eine lokale Kopie und eine externe 
Datenträger Kopie.

Danke für die Antworten.

Totomitharry schrieb:
> Vielleicht ist das nur der Overhead.

Das hängt von vielen Faktoren ab wie dem Dateisystem oder auch welche 
Parameter du angegeben hast. Mit rsync bildet man meist Prüfsummen und 
überträgt dann auch noch alle Timestamps, das braucht einfach etwas.

Und dann ist es natürlich auch noch die Frage ob man wirklich rsync 
selbst benutzt oder irgendwo ein ssh:// drinnen hat.

Gerade bei kleinen Dateien kannst du natürlich versuchen diese als 
tar/Stream zu packen und am Stück zu übertragen. Mache ich z.B. bei KODi 
Backups, zuerst werden die Dateien einfach gepackt und dann das Archiv 
übertragen. Geht schneller als scp/rsync ohne diesen Zwischenschritt.

Ein T. schrieb:
> was sync von copy unterscheidet... ;-)

Jetzt denken wir mal drüber nach das andere auch mal mehr wissen als man 
selbst.

Benutzt du denn auch rsync über ssh?
Siehe Option --rsh

Versuche es mal mit der -z option

1

       --compress, -z           compress file data during the transfer

2

       --compress-choice=STR    choose the compression algorithm (aka --zc)

3

       --compress-level=NUM     explicitly set compression level (aka --zl)

4

       --skip-compress=LIST     skip compressing files with suffix in LIST

Professioneller Regeditor schrieb:
> Benutzt du denn auch rsync über ssh?
> Siehe Option --rsh

Rsync nutzt schon seit vielen Jahren SSH als Standard. remote Shell 
schon lange nicht mehr.

🐧 DPA 🐧 schrieb:
> Versuche es mal mit der -z option

Warum? Liegt ja scheinbar nicht an der langsamen Netzwerkverbindung. 
Warum also die CPU noch weiter ausbremsen wollen? Dann lieber mit 
--inplace probieren (um die temporäre Datei zu vermeiden)

(Wobei bei mir läuft es auch ohne die Option mit der maximalen 
Geschwindigkeit die Netzwerk/NAS hergibt)