Alternative zu rsync

[Räuber Hotzenplotz]

Hallo,

ich möchte ca. 1,5 Terrabyte an Daten von einem Server auf einen externen Storage (per nfs) synchronisieren.

Mein erster Versuch war natürlich rsync. Jedoch erscheint mehrere Stunden die Ausschrift "receiving file list" und CPU-Last & Memoryauslastung gehen gegen 100%, da u.a. sehr viele kleine Dateien dabei sind.

Gibt es konsolenbasierte Alternativen, welche geänderte Dateien übertragen und vor allem nicht mehr vorhandene Dateien auf dem Spiegel löschen?

Vielen Dank!

[pluvo]

Gibt es konsolenbasierte Alternativen, welche geänderte Dateien übertragen und vor allem nicht mehr vorhandene Dateien auf dem Spiegel löschen?

Wie wäre es mit rsync?

Nein, mal ernsthaft, wie sieht denn dein rsync-Befehl aus. Vielleicht können wir den optimieren

mfg pluvo

[Räuber Hotzenplotz]

relativ simpel:

Code: Alles auswählen

/usr/bin/rsync -a --delete <SRC> <DEST>

Für weitere Parameter bin ich immer offen

Grüße,
Hotzi

[123456]

1,5 TB und tonnenweise kleine Dateien schafft jedes Programm. Das ist auch wohl eher ein Problem des Dateisystems.

Wie ist denn die Alternative zu bewerten den Haufen als Image (partimage? k.A. ob das damit zurechtkommt) zu schreiben und das zu übertragen? Danach kanns ja mit rsync weitergehen.

[devilx]

Wenn du die Daten sowieso nicht backuppen moechtest, sondern wirklich 1:1 Synchron haben willst (deinem --delete entnommen), waere die Frage ob vllt. ein Konstrukt mittels mdadm bzw. iSCSI nicht angebrachter waere? D.h. ein Software-RAID(1) ueber's Netz.

[suno]

Eine Alternative waere noch Unison -- wobei auch Unison den rsync Algorithums verwendet. Ich wuerde fuer das anfaengliche bilden der hashsums ganz einfach mit "nice" das process scheduling vom rsync beeinflussen d.h. einen passenden Wert vergeben sodass die Maschine fuer normale Dinge SSH etc. responsive bleibt.

Code: Alles auswählen

nice -n 15 <rsync_one-liner>

Die 1.5 TiB sind es nicht wert sich mehr anzutun (mdadm, iSCSI, etc.) wobei es imho ohnehin keinen besseren Weg gibt i.e. es muessen am Anfang einmal die hashsums gerechnet werden ... ab dem 2nd run geht es dann aber extrem schnell ...

[Räuber Hotzenplotz]

1,5 TB und tonnenweise kleine Dateien schafft jedes Programm. Das ist auch wohl eher ein Problem des Dateisystems.

Gut zu hören. Dateisystem ist ein ext3 auf einem LVM.

Wie ist denn die Alternative zu bewerten den Haufen als Image (partimage? k.A. ob das damit zurechtkommt) zu schreiben und das zu übertragen? Danach kanns ja mit rsync weitergehen.

Mit partimage hab ich bis jetzt noch nicht gearbeitet. Bei einem Image seh ich aber das Problem, dass immer das komplette File übertragen wird.

Hintergrund: Es handelt sich hierbei um ein Backup von dem ich periodisch noch ein Archiv sichern will. Da sich ja nun mal nicht alle Daten zwischen zwei Sync's ändern, wollte ich es elegant mit rsync angehen und nur die Änderungen übertragen.

Ein "cp -u ..." wäre auch eine erste triviale Lösung, jedoch werden im Backup gelöschte Dateien nicht auch im Archiv gelöscht. Oder gibt's da 'nen Parameter, den ich übersehen hab?

Wie schaut es mit tar aus? Gibt es da nicht irgendwelche Schweinereien um Verzeichnisse zu syncen?

[suno]

ha! LVM hat der Mann drunter. Sehr gut. Du machst also einen Snapshot mit LVM und syncst dann vom Snapshot. So garantierst du das waerend der Zeit des hashsums rechnen (syncen) sich die source nicht aendert und es zu einer ganzen Menge warnings etc. kommt.

Ausserdem kannst du dann alles on-line mahcen d.h. transparent fuer user, applications und daemons am source system.

Auf block layer zu sichern (dd & Co) ist wie du richtig erkannt hast keine Alternative ... du moechtest ja nicht jedesmal 1.5 TiB uebertragen.

Vergiss tar und andere home-made Sachen. LVM Snapshots und ein tool das den rsync Algorithmus verwendet d.h. entweder rsync selbst oder noch besser Unison.

[Räuber Hotzenplotz]

Wenn du die Daten sowieso nicht backuppen moechtest, sondern wirklich 1:1 Synchron haben willst (deinem --delete entnommen), waere die Frage ob vllt. ein Konstrukt mittels mdadm bzw. iSCSI nicht angebrachter waere? D.h. ein Software-RAID(1) ueber's Netz.

Das Problem ist, dass die Daten auf einen "preiswerten" NAS-Server übertragen werden sollen. Auf diesem kann ich ein paar Freigaben, Nutzer, etc. einrichten. Mehr aber auch nicht. Es läuft halt ein embedded Linux drauf und ich habe nicht die Möglichkeit, ins System einzugreifen.

[suno]

Hier noch ein link bez. LVM Snapshots http://www.ibm.com/developerworks/linux ... index.html

Wir verw. neben Veritas fuer Teile des SANs eine LVM Loesung genau so wie oben beschrieben. In Summe sichern/verwalten wir so in diesem Teil des SANs ca. 0.6 PiB an Daten. Filesystem ist XFS aber das ist eigenlich egal ... haben wir wegen der dynamischen Inode allocation etc. gewaehlt.

Weil dass alles so gut funktioniert wenn es einmal aufgesetzt ist haben wir jetzt mehr Zeit zum chillen im Garten http://feeds.gawker.com/~r/gizmodo/full ... ar-ii-bomb ;-]

[Räuber Hotzenplotz]

LVM-Snapshots zu verwenden ist ein guter Einwand. Werd ich machen.

In Kombination mit nice -15 kommt vielleicht/bestimmt was brauchbares bei raus. Zeit hat die Maschine ja tagsüber.

Weil dass alles so gut funktioniert wenn es einmal aufgesetzt ist haben wir jetzt mehr Zeit zum chillen im Garten http://feeds.gawker.com/~r/gizmodo/full ... ar-ii-bomb ;-]

Hier regnet es gerade. Da gibt's keine Zeit zum chillen.

Vielen Dank & schönes WE,
dat Hotze