rsync vs. zfs send|zfs receive
Problemstellung:
- die Daten eines auf MacOS X erstellten ZPools sollen auf eine OpenSolaris-Maschine uebertragen werden.
Gedankengang #1:
Es war schon spaet abends, wirklich nachgedacht wurde nicht, klein Sebastian startet ein rsync und denkt “so lang wird das schon nicht dauern”. Problematik dabei ist bzw. war allerdings, dass auf dem Pool u.A. auch diverse OpenSource-Projekte und -Sammlungen im Quelltext vorlagen, so z.B. pkgsrc, was ohne mit der Wimper zu zucken zu mehreren Millionen kleinen Files fuehrt. Ebenfalls kam der kleine Sebastian nicht auf die Idee fuer das rsync ein LAN-Kabel anzuschliessen und schickte den kompletten Datenstrom ueber WLAN durch die Luft. (Immerhin zwar n, aber im Vergleich zu Gigabit-Ethernet immernoch langsam.) Einigen wir uns auf keine so gute Idee, auch wenn sie zum Ziel gefuehrt hat.
rsync -avzP -e "ssh -p 22" /Volumes/tank/* shl@<ziel>:/tank/transfer
Gedankengang #2: (ein paar Tage spaeter)
Die Daten sind auf dem neuen Pool angekommen – so weit so gut. Und damit es noch einen Lern-Erfolg gibt, machen wir das jetzt nochmal in richtig. Damit ich den – in diesem Falle – ueberfluessigen Layer Netzwerk los werde, schliesse ich die USB-Platten vom Mac direkt an die OpenSolaris-Box an. Hierfuer muss der Pool allerdings erst umbenannt werden, da eine Maschine nicht zwei Pools des gleichen Namens mounten kann.
sudo zpool export tank
sudo zpool import oldtank tank
sudo zpool export oldtank
Die Schritte im Detail: wir exportieren den Pool, damit wir ihn per import <neu> <alt> umbenennen koennen und exportieren ihn nochmals, damit wir ihn an die andere Kiste anschliessen koennen. Hier noch ein
pfexec zpool import oldtank
und zumindest das erste Problem ist gegessen.
ZFS bietet von Haus aus eine durchdachte Moeglichkeit an um Daten von A nach B zu schieben, naemlich zfs send | zfs receive. Durch die Pipe (|) kann man hier auch prima z.B. ssh als Transport-Medium nutzen. Allerdings kann zfs send nur Snapshots uebertragen – aber bei einem Filesystem was effektiv still steht (hier oldtank) tut das ja nun wirklich nicht weh.
Das folgende Script habe ich die letzten Monate auf meinem Mac zum snapshot’en benutzt. In groben Zuegen basiert es auf Jeff’s Snapshot-Script, allerdings erstellen wir hier keinen Timestamp sondern einen hoffentlich eindeutigen String fuer die Snapshots die wir kopieren moechten, in diesem Falle “NOWITSTHETIME“.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | #!/bin/bash FS=`zfs list -t filesystem | grep oldtank | awk '/^[a-z0-9]+\//{ print $1}'` #NOW=`date +%Y-%m-%d` NOW=NOWITSTHETIME for I in $FS; do echo "Snapshot'ing ${I}@$NOW ..." zfs snapshot ${I}@$NOW if [ $? = 0 ]; then echo "success!" else echo "failed ($?)!" fi done |
Im naechsten Script – ich entschuldige mich im Vorfeld fuer die massive und z.T. unnoetige Nutzung von grep, aber mir gefaellt das halt so 
– schicken wir die eben erstellten Snapshots nach tank/transfer2 (vorher natuerlich anlegen, sonst wird das nix…):
1 2 3 4 5 6 7 | #!/bin/bash for i in `zfs list -rH -t snapshot | awk '{print $1}' | grep oldtank | grep -v tank/transfer2/oldtank | grep NOWITSTHETIME` do echo "sending Snapshot" $i "to transfer2" pfexec zfs send $i | pfexec zfs receive tank/transfer2/$i done |
Fragt sich nun natuerlich: was haben wir gewonnen?
zfs send serialisiert den Datenstrom, was z.B. dazu fuehrt, dass es vollkommen egal ist, ob wir mit Millionen von kleinen Dateien oder drei grossen 1TB-Files arbeiten. Ebenfalls koennen wir uns den kompletten Weg der Daten sicher ueber deren Zustand sein, denn wir vertrauen durchweg auf die Integritaetschecks von ZFS. Wenn gewuenscht (ich habe nicht wirklich einen Sinn darin gesehen) kann man durch die Pipes noch z.B. gzip einbauen, oder eben Transport-Mechanismen wir ssh oder sonstwas nutzen. Konstrukte wie
zfs send tank@BRIEFTAUBE > file
Benutze file mit Brieftaube
cat file | zfs receive tank@BRIEFTAUBE
sind genauso moeglich. Und auch die Nutzung als Backup ist durchaus eine Ueberlegung wert.
Um zur urspruenglichen Problemstellung zurueck zu kommen: im Vergleich zur Methode #1 ist die Loesung mit zfs send eindeutig schneller. Und – zumindest ich – habe damit ein besseres Gefuehl.
Beide Scripte sind per git auf github verfuegbar.
(git clone git://github.com/shl/zfssnapsend.git)
