zwei NAS Server (r)syncen

R

rakso

Well-Known Member
Hallo zusammen,

normalerweise mache ich backups wie folgt:

Code: 
 rsync  -az --numeric-ids --progress -e "ssh -p 22" --delete --delete-excluded   \
        --exclude-from=excludefile root@$SERVER:/data/ /data


Jetzt möchte ich 2 NAS-Server synchron halten.

Wenn ich aber rsync wie oben auf NAS1 starte, werden auf NAS1 gemachte lokale Änderungen überschrieben, in dem NAS2 1:1 rübergeschoben wird.

wenn man nun --delete weglässt, wird das klappen.

Wenn ich nun aber rechtmäßig dateien aus einem NAS lösche, möchte ich auch dass diese Änderung auf dem anderen übertragen wird.


Kann man überhaupt beide synchron halten, wenn auf beiden gleichzeitig (nicht mit den gleichen Dateien) gearbeitet werden kann?

Wie?


Grüße, rakso
 
Hi,

also hast möchte ich nicht verwenden, die verbindung ist auch relativ schwach.

Bummibaer schrieb:
Das ist Sync zu halten ist natürlich nur sinnvoll wenn auf beiden Kisten die selben Daten liegen sollen. An sonsten mit rsync was basteln wo Daten rübärjagt und andere löscht oder ned löscht geht natürlich auch.
Zum Vergrößern anklicken....
das wäre mir lieber. wie sieht denn sowas aus?
 
Wenn du ZFS hast, kannst du einen Snapshot machen und diesen per "zfs send" über SSH senden.
 
hi

wenn du zfs verwendestes kannst du mit snap replication arbeiten.
das geht sogar mit schwachen verbindugen recht gut.

im ports gibt es auch ein fertiges script was du nur noch im cron einbinden musst.

holger
 
wie heisst der port? und sind dann beidseitige änderungen berücksichtigt oder wird dann auch gnadenlos überschrieben? verwende zfs, ja.
 
rakso schrieb:
wie heisst der port? und sind dann beidseitige änderungen berücksichtigt oder wird dann auch gnadenlos überschrieben? verwende zfs, ja.
Zum Vergrößern anklicken....

hi

also es ist halt eine replication eines tanks

wenn du tank standort1 und einen standort2 hast kannst du diese entsprechen gegen
seitig replizieren .

es ist eine block replication die auf dem snap mechanissmus basiert.

du hast dann aber an jemdem standort 2 tanks auf dem nas.

schau mal in pors/sysutils

muesste vom namen zfsreplicate sein.

holger
 
ich glaub das is ned genau das, was ich brauch. mit rsync ne ebene drüber reicht.

aber genau hier stoß ich nun auf ein problem. nehmen wir an, ich hab auf srv1 neue dateien erstelle. dann starte ich auf srv1 den rsync mit srv2 - da es auf dem srv2 die dateien noch nicht gibt, werden die neuen auf srv1 gekillt (mit --delete )

das darf so nicht sein.

wenn ich --delete weglasse, werden "rechtmäßig" gelöschte dateien auf dem anderen nicht gelöscht, was auch käse ist.

wisst ihr, was ich meine? wie bekomm mich sowas hin?
 
Ich denke mit rsync kommst du nicht weiter wenn du in beide Richtungen syncen willst. Ein VCS wie hg oder git würde Funktionieren. Aber ich schätze mal du willst kaum den ganzen Platz für die History aufbringen.
 
Kamikaze schrieb:
Aber ich schätze mal du willst kaum den ganzen Platz für die History aufbringen.
Zum Vergrößern anklicken....
d.h.?

wenn ichs mir recht überlege, wäre HAST wohl genau das, was ich such. aber dann kann ich mein ZFS wieder platt machen und hoffen, dass ca 400kb/s DSL downstream auf der einen seite ausreichen.. denke das ist bissle knapp..
 
hm
sonst gibt es keine möglichkeit, z.b. rsync optionen, die die create time berücksichtigen? das würde dann wohl funktioneren, wenn dann die dateien neueren datums berücksichtigt werden.

--delete-after bringt leider nix


dann werde ich den Datenbestand auf der jeweils anderen kiste per samba nur ro bereitstellen um ein chaos zu vermeiden, und nur von hand, wenn ich weiss, wann wo was geändert wurde, nen sync machen. .. aber das ist ziemlich crappy..
 
Hoi,

VCS musst Du Dir so vorstellen als würdest Du einen Turnschuh quasi als Mamut langfristig aufblasen. Dafür ist dann abär nix gelöscht und alles verfügbar. D.h. im Endeffekt lebt das Teil dann von viel RAM und noch mehr Storage Kapazität.

Gruß Bär
 
hm ja.
hast du sonst noch ein vorschlag für mein problem , wie man das machen kann?

hab halt nen datenbestand, den ich mal an der einen örtlichkeit, mal an der anderen , bearbeiten möchte, aber dann jeweils an der anderen auch up2date haben möchte.
 
Hoi,
das ist und bleibt nur eine Frage vom Speicherplatz. Das Ganze steht und fällt damit - bärig oifach. Ich persönlich würde die Daten so syncen, dass auf allen Locations jeweils alles vorhanden ist. Das wäre mir die Flexibilität und Bequemlichkeit wert. Das setzt natürlich abär au den Platz voraus. Hier könnte man mit ZFS und viel RAM und günstigen SATA III Hds bärig was machen ohne arm zu werden.

Gruß Bummibär
 
Man sollte sich aber trotzdem auch mal mit den möglichen Konfliktmöglichkeiten beschäftigen. Die stehen bei Unison in der Doku.

Weil Multi-Master Replication ist alles andere als trivial.
 
Oh ja. Natürlich ist das irgendwo logisch, das Problem ist schließlich recht komplex, aber der deutliche Hinweis kann sicher nicht schaden. Besser als verlorene Dateien.
 
ergänzende Frage:

auf der einen kiste ist ein verzeichnis mit du -sh 11M, auf der anderen 3.8M groß

die dateien in den verzeichnissen zeigen bei ls die gleiche größe an.

kann das an unterschiedlichen zpool configs liegen?

auf der mit 3.8M wurde das dataset nur mit compression=on angelegt. auf der anderen, wo das verzeichnis bei du größer ist, mit -o copies=3 -o compression=lzjb

werden die daten also 3x vorgehalten/brauchen den dreifachen speicherplatz, also 3x 3,8MB= 11,4 , oder woran liegt das?
 
Es liegt an der unterschiedlichen Arbeitsweise der Tools:
- "zfs list" liest die internen Angaben der Datasets aus.
- "df" fragt die Anzahl unbelegter Blöcke ab.
- "du" gibt aus, was eine Datei tatsächlich auf der Platte belegt.
- "ls" gibt die Länge der Datei in Byte aus.
"zfs list" und "df" sind gleich, bis auf eventuelle Rundungsfehler. Allerdings betrachtet "zfs list" den ganzen Pool und die darin liegende Hierarchie der Datasets, was es für ZFS komfortabler macht. "du" gibt an, wie viele Blöcke eine Datei auf der Platte belegt. Daher kann die Ausgabe von "du" größer als die von "ls" sein. Genau dann, wenn durch Verschnitt Blöcke nur teilweise belegt sind. Gleichzeitig gibt "du" meist weniger als "df" aus, da die Metadaten des Dateisystems nicht beachtet werden. In deinem Fall siehst du ersteres. Auf der einen Kiste sind die Daten lediglich komprimiert. Auf der anderen sind sie komprimiert und 3x kopiert. Also gibt "du" ca. das Dreifache von "ls" aus.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben