• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

zfs-pool auf anderer Maschine spiegeln

mr44er

Well-Known Member
Themenstarter #1
Szenario: 2 Maschinen, beide haben gleich große zfs-pools.

Wie bekomme ich es am geschicktesten hin, dass von Server A der Pool 1:1 auf Server B gedrückt wird?

Hab die Kisten hier im LAN stehen, initial würde ich das so über GBit kopieren wollen, später dann nachts inkrementell automatisch in beide Richtungen an unterschiedlichen Standorten über VPN.

Lese ich mich da in zfs send/receive ein? Wenn ja, hat jemand mal eine händische Zeile für mich? Ich würde für einen ersten Test und aha-Effekt gerne erstmal nur ein kleines Dataset schieben, damit ich mir nix vergurke? Habe gerade kein 100%-aktuelles Backup zur Hand. Mich verwirrt im ersten Moment, dass ein snapshot überall gezeigt wird.
Code:
# zfs send tank/data@snap1 | zfs recv spool/ds01
Oder doch rsync?
 

pit234a

Well-Known Member
#2
Code:
zfs send -R  tank/data@snap1| zfs recv -Fduv spool/ds01
habe ich mir notiert, als ich das letztens mal gemacht hatte.
Bei mir waren die Pools beide lokal vorhanden (ich zog von SAS nach SSD um). Man kann auch einen ssh zwischen schalten, wenn es remote sein soll (ist in der Doku alles beschrieben) und dann auch inkrementell senden, wenn man erst mal übertragen hat.

https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/zfs-zfs.html
 

gadean

Well-Known Member
#3
Hier mal meine Notizen, das Ziel ist "tank/data/files" und die Quelle "tank/files".
Falls die Hardware etwas schwächer ist, kann man noch überlegen die Crypto bei ssh etwas runter zu drehen. Bei mir war das nicht nötig, da beide Server mehr als genug Rechenleistung hatten/haben und ich es auch nicht eilig hatte.
Code:
# old
zfs snapshot tank/files@bck

# new
zfs create tank/data
zfs allow -u username compression,mountpoint,create,mount,receive tank/data
zfs unmount tank/data

# old
zfs send tank/files@bck | pv | ssh -T newServer "zfs receive -Fv tank/data/files"

# new 
zfs list -t snapshot
zfs rollback tank/data/files@bck
zfs destroy tank/data/files@bck
zfs mount tank/data/files

# old
zfs destroy tank/files@bck
 

mr44er

Well-Known Member
Themenstarter #5
Bin jetzt noch auf unison und zrep gestoßen, da ich ja 2way-synchro brauche. Mhm...ich bin unschlüssig. :(
 

pit234a

Well-Known Member
#6
Ich sehe einen Unterschied zwischen "Klon-Projekt" und anschließendem "Sync-Projekt".
Für das "Klon-Projekt" würde ich zu zfs send | receive raten. Das ist bewährt und gut und sicher.
Für mein eigenes "Sync-Projekt" konnte ich mich nicht von rsync lösen und verstehe daher, dass man über Alternativen nachdenkt und sie auch einsetzt.
 

mr44er

Well-Known Member
Themenstarter #8
nicht von rsync lösen und verstehe daher, dass man über Alternativen nachdenkt und sie auch einsetzt
rsync hab ich mal bei 2 winzigen nas4free-Boxen am laufen gehabt. Das lief wartungsfrei und fix, es waren auch nur knapp 2Gb an Dokumenten, da war die Methode der Veränderungsprüfung egal.

Könnte man nicht auch hastd dafür verwenden?
Wäre wahrscheinlich was. Für den Hinterkopf: Apache und ein mailer sollen in ferner Zukunft redundant laufen. Wie ist das mit hastd...wird/muss der gesamte Server für den Zweck synchron gehalten oder kann man da Ausnahmen pro Kiste machen?
 

mr44er

Well-Known Member
Themenstarter #9
Aktuell hab ich auf einer einzelnen 4TB Platte gerade mal ein ZFS geworfen und backuppe die allerwichtigsten Daten drauf, bevor ich weitere Schritte unternehme.
Für den Lerneffekt und Kaltbackup ganz gut mal mit kleinen Brötchen anzufangen:

Code:
zfs send -v tank/data@snap1 | zfs receive backuppool/data
 

mr44er

Well-Known Member
Themenstarter #10
Ich habe mich jetzt mal für HAST entschieden. Auch aus Prinzip, damit ich das mal gemacht habe und ich bastel ja so gerne.

Bevor ich mir ins Knie schieße, Frage an die Experten:
Setze ich erst HAST, dann GELI, dann ZFS drauf oder sorum: GELI->HAST->ZFS?
 

mr44er

Well-Known Member
Themenstarter #11
Hab mich prompt wieder gegen HAST entschieden, das bringt nur was, wenn beide Maschinen an der selben Site eine schnelle Verbindung haben und ZFS meldet einen Plattenausfall (logischerweise) nicht und ich kann/sollte/will (HAST is dafür nicht ausgelegt/gedacht, hab ich gelesen) auf Site B (secondary role) die Daten nicht verändern.

Ich überlege jetzt immer noch hin und her, ob ich unison nutze...manuelles zfs send/receive nachts per cronjob oder sysutils/zrep.

Wie macht ihr das denn mit 2way-syncro, wenn die Daten auf ZFS liegen und zwischen beiden Servern ein lahmes WAN hängt?

Mein Ziel ist es, an beiden Standorten die Daten bearbeiten zu können und das gleicht sich ab inkl. gelöschten Dateien...entweder Site A oder Site B. Es muss nicht 'instant' geschehen, paar Minuten Verzögerung ist ok bzw. nachts laufen lassen, da die Leitung dann frei ist.
 
#12
Bin nur Heimnutzer.

"Automatisch in beide Richtungen" geht meiner Erfahrung nach nicht so trivial.

zfs send / receive funktioniert gut für Backup. Meiner Erfahrung nach kann (gibt es immer?) es Probleme geben, sobald das Backup verändert wird. Aus diesem Grund importiere ich den Backuppool immer mit dem parameter -N für "nicht mounten", ok, ich meine das liegt daran, daß ich root auf zfs habe, da wird doch meistens drauf geschrieben.


Ein nicht automatisch lösbares Problem scheinen mir Löschungen zu sein.

Für server mit nur einem root-Pool, und nur einem dataset, weiß ich keinen Ansatz.
Wenn Du aber nur ein/mehrere datasets synchronisieren willst, hätte ich einen Ansatz, den Du testen könntest.

Ist das was Du willst?
Also
ServerA/dateien
ServerB/dateien

auf beiden finden Änderungen statt, sollen aber das gleiche darstellen.

Ich könnte mir vorstellen, daß es mit beiderseitigen Backups und offline - Zeitfenster geht.
ServerA/dateien wird ausgehängt (zfs umount ServerA/dateien)
snapshot ServerA/dateien@snap1 erstellt,
mit zfs send/receive
an ServerB/backup/ServerA/dateien
gesendet
dann mit rsync ServerB/dateien/ ServerB/backup/ServerA/dateien
aktualisiert, (ist dann lokal, nicht übers Netz)
dann neuer zfs snapshot ServerB/backup/ServerA/dateien@snap2
incrementell senden ServerB/backup/ServerA/dateien@snap1 ServerB/backup/ServerA/dateien@snap2 | zfs receive ... ServerA/dateien

zfs mount ServerA/dateien

das gleiche spiel mit ServerB

sieht mir aber wackelig und fehleranfällig aus. Die Löschungen bleiben manuell zu klären, oder könnte man automatisch machen lassen, und danach manuell aus dem snapshot kopieren - braucht dann aber doppelten speicher - gelöschte vorhandene Datei im Snapshot und aus dem snapshot heraus kopierte Datei.
 

mr44er

Well-Known Member
Themenstarter #13
Ja, das triffts. rsync kann das und und löschen. Hatte ich mal im Einsatz, allerdings nur in eine Richtung.

Werde berichten, wenn ich was halbwegs ausgegorenes hingepfuscht hab. :)
 

mr44er

Well-Known Member
Themenstarter #14
So, bisher habe ich das alles was ich benötigte manuell angestupst, fühle mich da mittlerweile auch relativ sattelfest damit. Der Tipp, alles über nc zu pipen ist grandios, die Bandbreite wird voll ausgelastet und das ohne die mtu anzufassen. Ich pipe das auf Senderseite noch durch pv und sehe die Übertragungsgeschwindigkeit. :)

Bevor ich das alles in Richtung Automatik hieve, kommen natürlich Fragen, um es weiter zu optimieren. Meine pools und datasets sind mit lz4 komprimiert.
Wenn ich einen zfs stream sende, ist dieser stream dann bereits komprimiert oder nicht?
Wenn nein, sollte ich ihn mit gzip pipen oder gibts da was besseres?
 

gadean

Well-Known Member
#15
Ich würde einfach mal ein dataset normal und einmal mit pigz übertragen und schauen wie die Performanz und Belastung ausschaut.
 

mr44er

Well-Known Member
Themenstarter #18
Weil dazwischen nur 10MBit Upstream sind und weil der Standort jeweils unabhängig vom anderen und unabhängig von der Bandbreite auskommen muss/soll.