rSync / Extreem veel dataverkeer

[WhiteDog]

Ik maak sinds kort gebruik van rsync om wat data over te zetten tussen 2 internet servers.
De bestanden die overgezet orden zijn "rsync friendly" backups in gzip formaat.
Daarnaast is rsync correct geconfigureerd (--no-W) om gebruik te maken van delta transfers

Zie ook een printout van --stats:

Number of files: 288
Number of files transferred: 127
Total file size: 52.48G bytes
[b]Total transferred file size: 15.66G bytes[/b]
Literal data: 424.88M bytes
Matched data: 15.23G bytes
File list size: 6.97K
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
[b]Total bytes sent: 428.69M[/b]
Total bytes received: 6.57M

Dat lijkt op het eerste zicht OK. Echter in de grafiekjes van de servers zie ik dat zowel de servers aan beide kanten (source / target) massaal veel IO doen: Elk zo'n 50 GB in én uit sinds ik begonnen ben met rsync.

Ik vermoed dan ook dat ik ergens een katastrofale denkfout gemaakt heb

Ik rsync namelijk naar een nfs mount aangemaakt als volgt:

mount -t nfs server.domein.nl:/backup/server /mnt/backup

en voer vervolgens dit uit:

rsync -tr --no-W /backup/daily /mnt/backup

Mijn vermoeden is nu dat rsync dit als een lokale folder behandelt en vrolijk langs client-side de hele file binnenhengelt om zijn checksums op te berekenen (in plaats van aan de andere kant te vragen dit te doen). Dit zou alvast verklaren waarom er ook zoveel data binnenkomt...

Is er iemand die dit vermoeden even kan bevestigen zodra hij klaar is met lachen?

[DutchNutcase]

Waarom gebruik je hier nfs voor? rsync werkt erg goed met SSH, gebruik de switch -e ssh.

[terual]

Om rsync te laten bepalen wat de delta is tussen bestanden heb je inderdaad remote shell toegang nodig. De meest veilige manier is ssh. Toegang tot het remote bestandsysteem voldoet inderdaad niet om de redenen die je al aangeeft. Als je rsync via ssh gebruikt logt rsync als het ware in op de remote host om daar ook een instantie van rsync te laten draaien.

[WhiteDog]

terual schreef op zaterdag 04 augustus 2012 @ 09:00:
Om rsync te laten bepalen wat de delta is tussen bestanden heb je inderdaad remote shell toegang nodig. De meest veilige manier is ssh. Toegang tot het remote bestandsysteem voldoet inderdaad niet om de redenen die je al aangeeft. Als je rsync via ssh gebruikt logt rsync als het ware in op de remote host om daar ook een instantie van rsync te laten draaien.

DutchNutcase schreef op zaterdag 04 augustus 2012 @ 08:05:
Waarom gebruik je hier nfs voor? rsync werkt erg goed met SSH, gebruik de switch -e ssh.

Het feit dat ik nfs gebruik komt doordat die folder al gemapt was uit een ver verleden en ik dat domweg hergebruikt heb. Daarnaast gebruik het hetzelfde commando (zonder --no-W) ook voor 2 servers die via gbit met elkaar verbonden zijn en dat doet het al jaren goed

Ik heb er alleen nooit bij stilgestaan dat, door nfs te gebruiken, maar één kant al het werk deed..

[Osxy]

50GB IO klopt wel, dat is disk lees operaties. Rsync leest de totale data om te zien wat gewijzigd is, anders kan het niet vergeleken worden.

Tenzij het 50GB netwerk verkeer is, dan gaat het goed fout. Maar ik vermoed dat het een simpele denkfout is . Anders zou heel goed de NFS data mount kunnen zijn.

[ Voor 9% gewijzigd door Osxy op 04-08-2012 10:39 ]

[WhiteDog]

Osxy schreef op zaterdag 04 augustus 2012 @ 10:38:
50GB IO klopt wel, dat is disk lees operaties. Rsync leest de totale data om te zien wat gewijzigd is, anders kan het niet vergeleken worden.

Tenzij het 50GB netwerk verkeer is, dan gaat het goed fout. Maar ik vermoed dat het een simpele denkfout is . Anders zou heel goed de NFS data mount kunnen zijn.

Ik heb het wel degelijk over 50 GB netwerkverkeer (in én uit). We gaan even met SSH proberen