ZFS Snapshots
Eine wirklich geile Funktion von ZFS sind Snapshots. Macht man einen Snapshot friert ZFS den aktuellen Stand des Dateisystems einfach ein. ZFS schreibt so oder so jede Änderung an eine neue Stelle (copy on write). Die Blöcke werden bei einem Snapshot einfach nicht mehr zum überschreiben freigegeben. Somit ist es für ZFS einfacher einen Snapshot zu machen als eine Datei zu speichern. Einen snapshot kann man natürlich einfach wiederherstellen, auf diesen Zugreifen (um sich mal schnell eine versehentlich gelöschte Datei aus diesem heraus zu kopieren), ihn wiederherstellen oder aus ihm einen beschreibbaren Clone erstellen. Wenn gewünscht kann man einen Snapshot oder nur die Veränderung zwischen zwei Snapshots per SSH auf einen anderen Rechner schieben. Dabei werden natürlich alle Einstellungen der Dateisysteme (NFS Shares, SMB Shares, ISCSI Targets, Quotas usw. usw…) übernommen. Man kann also für 0€ seinen Store auf eine andere Maschine Spiegeln. Als Sicherung oder für den failover!
Ich habe mir für meinen Test nun erstmal einen neuen ZFS Pool mit dem Namen wurstpelle angelegt. In diesem habe ich schnell das ZFS Volume bernd angelegt und diesem eine Quota von 10GB sowie eine Reservierung von 3GB verpasst:
$ zpool create wurstpelle c3d0p0
$ zfs create wurstpelle/bernd
$ zfs set quota=10G wurstpelle/bernd
$ zfs set reservation=3G wurstpelle/bernd
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
...
wurstpelle 3,00G 70,3G 32K /wurstpelle
wurstpelle/bernd 31K 10,0G 31K /wurstpelle/bernd
In diesem erstelle ich nun schnell 1GB Testdateien (10 Stück je 100MB):
$ dd if=/dev/zero of=/wurstpelle/bernd/image01.img bs=10240 count=10240
10240+0 records in
10240+0 records out
$ ls -lh
total 204833
-rw-r--r-- 1 root root 100M Okt 31 15:21 image01.img
$ cp image01.img image02.img
$ cp image01.img image03.img
$ cp image01.img image04.img
$ cp image01.img image05.img
$ cp image01.img image06.img
$ cp image01.img image07.img
$ cp image01.img image08.img
$ cp image01.img image09.img
$ cp image01.img image10.img
$ ls -lh
total 1993042
-rw-r--r-- 1 root root 100M Okt 31 15:21 image01.img
-rw-r--r-- 1 root root 100M Okt 31 15:21 image02.img
-rw-r--r-- 1 root root 100M Okt 31 15:21 image03.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image04.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image05.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image06.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image07.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image08.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image09.img
-rw-r--r-- 1 root root 100M Okt 31 15:22 image10.img
Mal schauen wie voll der Pool nun ist:
$ zfs list wurstpelle/bernd
NAME USED AVAIL REFER MOUNTPOINT
wurstpelle/bernd 1000M 9,02G 1000M /wurstpelle/bernd
Nun erstelle ich vom Dateisystem bernd mal einen Snapshot:
$ zfs snapshot wurstpelle/bernd@Test-snapshot>
Diesem Snapshot muss ich natürlich einen Namen geben, das passiert ab dem @. Mein Snapshot heißt also nun Test-snapshot. Ab diesem Moment gibt es unter /wurstpelle/bernd einen Ordner mit dem Namen „.zfs“ diese ist per default nicht sichtbar. Selbst mit einem ls -lisa nicht:
$ ls -lisa
total 2048352
4 3 drwxr-xr-x 2 root root 12 Okt 31 15:22 .
4 3 drwxr-xr-x 3 root root 3 Okt 31 15:17 ..
8 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:21 image01.img
9 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:21 image02.img
10 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:21 image03.img
11 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image04.img
12 204849 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image05.img
13 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image06.img
14 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image07.img
15 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image08.img
16 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image09.img
17 204833 -rw-r--r-- 1 root root 104857600 Okt 31 15:22 image10.img
Ich kann aber mit einem cd einfach in diesen Ordner wechseln. In diesem gibt es einen Ordner snapshot und hier liegt mein Test-snapshot:
$ cd .zfs
cd snapshot/
$ ls -lh
total 3
drwxr-xr-x 2 root root 12 Okt 31 15:22 Test-snapshot
Cool, hm? Wechsel ich nun in den Snapshot schaut alles aus wie mein Dateisystem zum Zeitpunkt des Snapshots. Ich kann Dateien öffnen, sie herauskopieren, ich könnte den Snapshot sogar als Backup wegsichern!
Snapshot/Backup/wegsichern?!?!? Joar… Wie wäre es mit einem Einzeiler auf der Bash um ein komplettes Dateisystemabbild auf einen anderen Rechner zu schieben? Kein Problem!
Auf dem Quellsystem ist nicht viel zu beachten. Es muss halt einen Snapshot geben, welchen man herüber schieben will. Den zu erstellen ist ja kein Problem 😛 Auf dem Zielsystem ist genau so wenig zu beachten. der SSH-Loginuser muss halt das Recht haben ein neues ZFS-Volume anzulegen.
Ich teste ja mit Openindiana, für einen Test erlaube ich dann mal auf der Openindianakiste den root Login per ssh:
### enable root ssh login ###
$ rolemod -K type=normal root
$ cat /etc/ssh/sshd_config |grep PermitRootLogin
PermitRootLogin yes
Nun lege ich noch schnell einen ZFS Pool an in welchem ich die Daten gerne liegen hätte:
$ zpool create backup c2d1p0
$ zpool list backup
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 74,5G 132K 74,5G 0% 1.00x ONLINE -
Schon kann es los gehen. Mit folgendem Befehl stoße ich nun also auf meinem Quellsystem die „Kopie“ an:
$ zfs send wurstpelle/bernd@Test-snapshot | ssh root@xxxx:xxxx:8001:0:2e0:4cff:feee:8adb zfs recv backup/daten-ziel@Test-snapshot>
Password:
Fertig? Joar, nun schaue ich mal ob alles angekommen ist:
$ zpool list backup
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup 74,5G 1001M 73,5G 1% 1.00x ONLINE -
$ ls -l /backup/
total 2
drwxr-xr-x 2 root root 12 2011-10-31 15:22 daten-ziel
$ ls -lh /backup/daten-ziel/
total 1001M
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image01.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image02.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image03.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image04.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image05.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image06.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image07.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image08.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image09.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image10.img
Alles da, alles gut. Nun könnte ich alle 10 Minuten einen Snapshot machen und jeweils den Unterschied der Snapshots auf mein Backupsystem schieben. Damit hätte ich eine genaue Kopie meines Livesystems mit maximal 15 Minuten unterschied. Auf dem Backupsystem könnte ich natürlich genau so Snapshots machen und den Backupstand zusätzlich sicher. Krass oder?
Für den Gnome Dateimanager Nautilus unter Opensolaris basierenden Systemen gibt es ein ganz nettes Plugin. Den Time Slider… Hier gibt es einen Dienst der alle paar Minuten einen Snapshot vom Sytem macht. Diese werden dann aufgehoben (Stündlich, täglich, wöchentlich, monatlich, jährlich….) Wir die Platte zu voll werden immer die ältesten Snapshots automatisch gelöscht. Durch das Nautilus Plugin kann man dann ganz bequem per GUI durch die Snapshots sliden. Ich habe da mal zwei Screenshots gemacht:
Aber da geht noch mehr… Ich sag nur Solaris boot environment 😀
Macht man ein Update seines Systems, macht der Updater einen Snapshot des root Pools, erstellt davon einen Clone und trägt diesen selbstständig im Grub ein. Dann macht er alle Updates in diesen neuen Pool. Es werden also nicht alle möglichen Dienste während des Updates neu gestartet oder sonstiges Zeugs…. Ist das Update abgeschlossen startet man seine Kiste einfach neu und Bootet in diesen neuen Clone (boot environment). Ein Update ist also in der Zeit eines Reboots erledigt. Ist bei dem Update etwas schief gelaufen, kann man einfach in alte System booten und alles ist wie vor dem Update. Kein Stress mehr, kein Bangen, keine Ausfälle während der Updates.
// Ich kann mich da an Updates auf Linux Servern erinnern, bei denen etwas mit dem Netzwerk oder SSH-Server schief gelaufen ist und man dann zum Server fahren musste (pre IPMI) oder an Windows Server die zwar ihre Updates installieren aber erst nach dem zweiten Reboot wieder (darf man stabil sagen?) stabil laufen. Über die boot environments muss man darüber nicht mehr nachdenken, zumindest bei Solaris und öhm BSD 😛 //
Dabei muss es sich nicht immer um ein Systemupdate handeln. Hin und wieder fummelt man ja gerne in einigen Konfigurationen herum. Warum macht man nicht einfach vor Experimenten ein neues Boot Environment von Hand? Kostet nichts und ist mit einem Befehl erledigt. Verfriemelt man sich, bootet man einfach lächelnd den alten Stand und fertig!
Alles läuft im Grunde über den Befehl beadm….
Was gibt es bisher:
$ beadm list
BE Active Mountpoint Space Policy Created
Sebastians-Notebook - - 36,1M static 2011-10-25 10:49
openindiana NR / 11,6G static 2011-09-28 19:06
openindiana-1 - - 37,3M static 2011-10-27 20:04
Ein neues anlegen:
$ beadm create NAME
Löschen mit destroy… Ach, einfach mal selbst schauen, ist sehr einfach!
