rsync > nur versteckte Dateien

C

codex

Aktives Mitglied
Thread Starter
Dabei seit
17.02.2009
Beiträge
193
Reaktionspunkte
3
Hallo zusammen.
Ich möchte einzelne Ordner mit dem Befehl rsync über Netzwerk auf einen Windows Rechner sichern. Der Befehl funktioniert zwar, allerdings sind die Dateien, die kopiert wurden (also die Backup-Dateien), alle "versteckt".
hier meine Kommandozeile:

rsync -aze ssh --progress /..... /......

Kann mir jemand sagen, wo das Problem liegt?


Edit: Möchte meine Frage erweitern: Habe ein weiteres Problem bzgl. der Geschwindigkeit wenn ich über Netzwerk das Backup durchführen will. Ich erreiche maximal 20MB/s mit rsync obwohl ich, wenn ich die Dateien manuell kopiere, bis zu 100mb/s schnell bin. habe mittlerweile die Option -z entfernt. Wenn ich das Ziel lokal definiere, ist alles extrem schnell....
auch da: jemand ne Idee?


Grüße
 
Zuletzt bearbeitet:
1. sind die ordner unter windows auch versteckt? wie sind die dateirechte?
2. lass mal --progress weg. -z nimmt man nur bei sehr schnellen rechnern/disks, ansonsten eher bei langsamen leitungen.
 
-z ist bei schnellen Rechnern/Disken sogar kontraproduktiv und eigentlich nur dann sinnvoll, wenn die Leitung zwischen Quelle und Ziel dünner ist als die Schreibrate des Ziels. Ansonsten ist unkomprimierte Übertragung immer schneller.

Was für einen rsync-Server respektive was für ein Gegenstück hast du unter Windows laufen?
 
mj schrieb:
-z ist bei schnellen Rechnern/Disken sogar kontraproduktiv
Zum Vergrößern anklicken....

Weil? Bei schnelle Rechner -- denke ich mal -- gehst du nicht von einem NAS aus und die gzip compression ist sehr wahrscheinlich in solch einem Fall nicht CPU bound, somit lohnt sicht die Kompressierung (natürlich abhängig von den Daten).
 
Natürlich ist die Kompression abhängig von der CPU, wer sonst soll denn komprimieren? ;)

Das Problem ist nur: gzip ist nur single-threaded (es gibt eine multi-threaded Version namens pigz, allerdings setzt rsync auf die Standard gzip-Libraries) und kommt selbst bei der schnellsten CPU ab spätestens 60-80 MB/s einfach nicht mehr mit. Das heißt selbst auf einem 44-Core-Monster wird nur ein einzelner Kern verwendet, wenn du allerdings von einem schnellen Array auf ein anderes schnelles Array kopierst (ich rede hier nicht von internen Platten mit ~60-100 MB/s, wobei auch hier schon je nach CPU gzip zum Flaschenhals werden kann, sondern von schnellen 200+ MB/s RAID-Arrays) dann ist das blanke sequentielle Kopieren schlichtweg schneller als wenn jedes Byte vorher durch einen Core geschleift, komprimiert und anschließend vom selben Core (!) wieder dekomprimiert werden muss.

Hier mal ein Beispiel: 2GB große Testdatei (erstellt mit dd if=/dev/zero of=/archiv/testdatei bs=10M count=200) auf einem externen SAS3-Array (6GB/s, 24x 7.200rpm 4TB Platten RAID6) auf ein identisch ausgestattetes baugleiches zweites SAS3-Array. Das ganze auf einem 20-Core 3 GHz Xeon-Server unter RHEL6:


Unkomprimierte Übertragung ohne gzip:
Code: 
root@ebdbak001/9 /archiv> rsync -avP /archiv/testdatei /mnt/ebdsto015_lun0/
sending incremental file list
testdatei
  2097152000 100%  188.69MB/s    0:00:10 (xfer#1, to-check=0/1)

sent 2097408075 bytes  received 31 bytes  182383313.57 bytes/sec
total size is 2097152000  speedup is 1.00

Komprimierte Übertragung mit gzip:
Code: 
root@ebdbak001/9 /archiv> rsync -avPz /archiv/testdatei /mnt/ebdsto015_lun0/
sending incremental file list
testdatei
  2097152000 100%   56.01MB/s    0:00:35 (xfer#1, to-check=0/1)

sent 2039407 bytes  received 31 bytes  55875.01 bytes/sec
total size is 2097152000  speedup is 1028.30

 
Was genau die definition von CPU bound ist.
 
Irgendwie verstehe ich nicht, was du mir sagen willst. Oder wir reden aneinander vorbei, was auch gut möglich ist.

Ich sage: Kompression bei schnellen Disken ist kontraproduktiv
Du sagst: Wieso? Ist doch nicht CPU bound, also müsste es sich doch lohnen?
Ich sage: Doch, weil eben doch von der CPU abhängig und nur single-threaded.
Du sagst: Sag ich doch.

Irgendwie bin ich jetzt ordentlich verwirrt :D Und den TE haben wir glaub ich grad durch unser fachsimplen vertrieben...
 
Du hast ja nichtmal ein anständiges Beispiel geliefert. Dein rsync Beispiel produziert nur Overhead, mehr nicht. Deine Kiste komprimiert deine 2GB Datei, dann dekomprimiert es wieder und speichert es auf eine physikalisch angebunde SAS? Wo bitte soll da der Gewinn sein, wenn die Dekomprimierung nicht auf einem externen Host geschieht, und die Daten komprimiert über eine -- sonst ausgelastete -- Netzwerkleitung gehen? Wie sollen sonst die Daten unkomprimiert auf dem Ziel landen, wenn in deinem Fall nicht auch von dem Rechner, der sie auch komprimiert?! Ich weiß echt nicht, was mir das Beispiel zeigen soll überhaupt.

Ich hab gesagt Komprimierung lohnt sich bei schneller Kiste(!) (== schnelle CPU) , falls nicht CPU bound. Ich hab nichts über Disks gesagt. Dein Beispiel ist offensichtlich CPU bound, sagst du ja selbst.

Du hast schon recht in deinem Beispiel, keine Frage. Bei einer 10GBit/s Leitung mit 300MB/s Durschsatz an Disks lohnt sich auch keine Komprimierung. Man muss halt immer an der Hardware und den Daten selbst entscheiden.
 
Oder anders ausgedrückt. Wie soll sich denn Kompression bei einer nicht schnellen CPU lohnen können?
 
Auch bei einer langsamen CPU lohnt sich Kompression, wenn die CPU mit höherer Bandbreite komprimieren kann, als die Leitung zwischen Quelle und Ziel dick ist.

Beispiel: habe ich nur eine 10 Mbit MPLS-Leitung zwischen zwei Standorten, lohnt sich Kompression bei der Übertragung durchaus, weil eine halbwegs moderne CPU einen deutlich höheren Kompressionsdurchsatz als 10 Mbit/s hat. Wird die Leitung allerdings dicker als die Kompressionsgeschwindigkeit der CPU, habe ich also z.B. eine 1 Gbit LWL-Standleitung oder einen Port-Channel aus mehreren 1 Gbit Leitungen zur Verfügung, lohnt sich Kompression nicht mehr. Dabei ist es völlig unerheblich, ob Kompression und Dekompression auf demselben System oder auf unterschiedlichen Systemen stattfinden.
 
Ja ne, ich weiß nicht, wieso du mir das offensichtliche hier erklärt, und absichtlich meine Überspitzungen falsch liest.

Du weißt offensichtlich was CPU bound ist, und was I/O bound ist. Und durch meine 3 Beiträge wird doch offensichtlich klar was ich meine:

xentric schrieb:
[..] und die Daten komprimiert über eine -- sonst ausgelastete -- Netzwerkleitung gehen[..]

Ich hab gesagt Komprimierung lohnt sich [..] falls nicht CPU bound.
Zum Vergrößern anklicken....

Und GENAU dann lohnt sich Komprimierung, sonst nicht. Und genau das sagst du auch. Nur das du dir heir Musterbeispiele an Fällen zusammenzimmerst um meine Überspitzungen zu wiederlegen.

Ist alles gut ..
 
@Olivetti und mj:
Also: Die Dateien sind in Windows auch versteckt. Die Rechte: "System", "Administrator", User, mit dem ich mich über Mac eingeloggt haben, und irgendwas komisches "S-1........."

Komprimierung habe ich mal entfernt, ohne Erfolg. Allerdings wird dadurch rsync lokal sehr viel schneller (von SSD auf SSD), nicht aber im LAN.

Gegenstück ist ein Freigegebener Windows Ordner. Wenn ich darin manuell kopiere über die Finder Oberfläche, ist die Verbindung sehr schnell. (ca. 100MB/s).
 
kopier mal testweise ein großes file via scp auf den WIN. evtl. hakt's wegen ssh.
 
dann weisst du jetzt, dass es eher nicht an rsync, sondern an deinem ssh liegt.
dreh' das logging auf beiden seiten auf, dann siehst du evtl. ja, wer die bremse verursacht.
 
Olivetti schrieb:
dann weisst du jetzt, dass es eher nicht an rsync, sondern an deinem ssh liegt.
dreh' das logging auf beiden seiten auf, dann siehst du evtl. ja, wer die bremse verursacht.
Zum Vergrößern anklicken....

ok jetzt bin ich überfordert ^^. Was meinst du mit Logging "aufdrehen"?
Also Übertragung ohne Verschlüsselung? Wie kann ich das realisieren? "ssh" in der Kommandozeile weglassen funktioniert nicht.

Noch jemand ne Idee dazu, warum alles "versteckt" ist?
 
zum beispiel "scp -v" auf senderseite, dann wieder in die logfiles gucken. auf WIN musst du selber schauen.
mit verschlüsselung weglassen hat das nichts zu tun.

hast du mit rsync eigentlich schonmal geprüft, ob auf WIN alles korrekt ankommt, evtl. liegt darin die "verstecktheit".

wenn du sagst mit finder ist alles schnell, wo liegt denn die freigabe überhaupt, bei dir im LAN?
 
Freigaben liegen im Heimnetzwerk, ja.
Die Dateien werden alle richtig übertragen, alles vorhanden und komplett....

Das mit der Geschwindigkeit klappt einfach nicht.... weiß nicht wo ich suchen soll.


Trotzdem danke an alle die geholfen haben.
 
---
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten