Mein Datenhaufen zu IT und Elektronik Themen.

Schlagwort: ZFS

FreeBSD 13 unverschlüsseltes ZFS Dataset/Jail zu verschlüsseltem ZFS Dataset/Jail

Mit FreeBSD 13 lässt sich die native ZFS Verschlüsselung direkt nutzen. Dabei muss man zwischen einem komplett verschlüsselten zpool und verschlüsselten Datasets unterscheiden. Hat man einen komplett verschlüsselten zpool, bedeutet es nicht, dass damit auch alle Datasets verschlüsselt sein müssen, so wie es auch nicht bedeutet, dass man Datasets nur verschlüsseln kann, wenn auch der komplette ZFS Pool verschlüsselt ist.

Wer nun also sein FreeBSD auf Version 13 gehoben hat, möchte ggf. einzelne ZFS Datasets verschlüsseln. In der Praxis trifft dieses sicher oft auf Jails zu. Diese liegen in der Regel in eigenen ZFS Datasets und mit dem folgenden Beispiel lassen sich diese und andere Datasets nachträglich verschlüsseln.

Im Beispiel haben wir den Pool zroot und in diesem das Dataset varta. Weder der zpool noch das Dataset sind aktuell verschlüsselt:

root@testtest:/ # zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  12.0G      100M  /zroot/varta
root@testtest:/ # zfs get encryption zroot/varta
NAME         PROPERTY    VALUE        SOURCE
zroot/varta  encryption  off          default
root@testtest:/ #

Aktiviert man bei ZFS Dinge wie Komprimierung oder Deduplikation sind diese immer nur ab dem Moment der Aktivierung und bis genau zur Deaktivierung aktiv. Dieses hat viele Vorteile aber auch Nachteile. So greift dieses nur für Daten, welche neu geschrieben werden. Möchte man dieses nachträglich auf alle Daten anwenden, muss man die Daten komplett neu schreiben. Dieses lässt sich am einfachsten und schnellsten per zfs send und zfs receive erledigen. Wenn man also sein bestehendes Dataset verschlüsseln möchte, dann geht dieses faktisch nicht, sondern man erstellt im Grunde ein neues verschlüsseltes Dataset und schreibt seine Daten dort rein.

Bevor wir nun mit der Migration starten, müssen wir noch eine Kleinigkeit wissen…. Zum Verschlüsseln der Daten benötigen wir noch ein Geheimnis, einen Schlüssel/Key. Dieser kann bei ZFS in verschiedenster Form und an verschiedensten Orten liegen. So könnte man den Key zur Ver- und Entschlüsselung auf einen USB-Stick ablegen. Nur wenn dieser auch im System steckt usw. usw.. Der eingängigste Weg ist sicher ein Passphrase welches per prompt abgefragt wird. Will man sein verschlüsseltes Dataset öffnen, wird man nach einem Kennwort gefragt, welches sich das System bis zum nächsten Reboot oder dem manuellen „Schließen“ des Datasets merkt. Diesen Zustand wollen wir nach der Migration, in diesem Beispiel, erreichen.

Zur Verdeutlichung erstellen wir kurz ein neues verschlüsseltes Dataset:

root@testtest:/ # zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt zroot/enc-beispiel
Enter passphrase:
Re-enter passphrase:

Damit haben wir ein neues Dataset welches sofort benutzt werden kann, alles was wir in dieses legen, ist verschlüsselt.

root@testtest:/ # zfs list zroot/enc-beispiel
NAME                 USED  AVAIL     REFER  MOUNTPOINT
zroot/enc-beispiel   200K  12.0G      200K  /zroot/enc-beispiel

Schauen wir in die Optionen des Datasets ist die Verschlüsselung aktiviert und der Schlüssel wird per Prompt vom Benutzer abgefragt:

root@testtest:/ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel
NAME                PROPERTY     VALUE        SOURCE
zroot/enc-beispiel  encryption   aes-256-gcm  -
zroot/enc-beispiel  keylocation  prompt       local
zroot/enc-beispiel  keyformat    passphrase   -

Wie immer wird das Dataset sofort eingehangen:

root@testtest:/ # mount |grep enc-beispiel
zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)

Nach einem reboot, wird das Dataset nicht automatisch eingehangen, da ZFS den Schlüssel nicht hat. Wenn wir es nun einhängen und ZFS anweisen, den Schlüssel zu laden (Option -l), dann werden wir zur Eingabe des Kennwortes aufgefordert und können das Dataset im Anschluss wieder nutzen:

root@testtest:~ # mount | grep enc-beispiel
root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel
NAME                PROPERTY     VALUE        SOURCE
zroot/enc-beispiel  encryption   aes-256-gcm  -
zroot/enc-beispiel  keylocation  prompt       local
zroot/enc-beispiel  keyformat    passphrase   -
root@testtest:~ # mount | grep enc-beispiel
root@testtest:~ # zfs mount -l zroot/enc-beispiel
Enter passphrase for 'zroot/enc-beispiel':
root@testtest:~ # mount | grep enc-beispiel
zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)

Gut gut… So viel zu den Basics. Damit ist nun auch klar, warum im nun folgenden zfs send / zfs reveive Beispiel, der Schlüssel einen Umweg nehmen wird. Denn durch das pipen kommen wir so schlecht an die stdin heran, um das Passphrase einzugeben 😉 Wir sind nun also wieder zurück bei unserem unverschlüsselten Dataset varta und dessen Migration in einen verschlüsselten Zustand. Als erstes legen wir nun das gewünschte Passphrase in einer Datei ab:

root@testtest:~ # echo 'Tolles-Kennwort' > /kennwort.txt
root@testtest:~ # cat /kennwort.txt 
Tolles-Kennwort

Ebenfalls erstellen wir einen snapshot vom Dataset varta, welchen wir zur Migration nutzen:

root@testtest:~ # zfs snapshot zroot/varta@migration
root@testtest:~ # zfs list -t snapshot
NAME                    USED  AVAIL     REFER  MOUNTPOINT
zroot/varta@migration     0B      -      100M  -

Jetzt kann die eigentliche Migration starten:

root@testtest:~ # zfs send zroot/varta@migration | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///kennwort.txt zroot/en-varta
root@testtest:~ # zfs list zroot/varta zroot/en-varta
NAME             USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta   100M  11.8G      100M  /zroot/en-varta
zroot/varta      100M  11.8G      100M  /zroot/varta
root@testtest:~ # zfs list -t snapshot
NAME                       USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta@migration   112K      -      100M  -
zroot/varta@migration        0B      -      100M  -

Das ist schnell und einfach, oder? Natürlich liegt nun noch immer das Passphrase offen in einer Datei im root des Systems. Wir müssen nun also den Ort des Schlüssels auf prompt ändern:

root@testtest:~ # zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE                 SOURCE
zroot/en-varta  keylocation  file:///kennwort.txt  local
root@testtest:~ # zfs set keylocation=prompt zroot/en-varta
root@testtest:~ # zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE        SOURCE
zroot/en-varta  keylocation  prompt       local

Damit kann die Datei mit dem Passphrase gelöscht werden:

root@testtest:~ # rm /kennwort.txt

Ebenfalls kann nun auch das unverschlüsselte Dataset weg:

root@testtest:~ # zfs destroy -r zroot/varta

Wenn man nun möchte, kann man das neue Dataset natürlich an die gleiche Stelle mounten oder direkt komplett gleich dem alten benennen:

root@testtest:~ # zfs rename zroot/en-varta zroot/varta

Damit ist die Migration fertig und das Dataset ist verschlüsselt:

root@testtest:~ # zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  11.9G      100M  /zroot/varta
root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/varta
NAME         PROPERTY     VALUE        SOURCE
zroot/varta  encryption   aes-256-gcm  -
zroot/varta  keylocation  prompt       local
zroot/varta  keyformat    passphrase   -

Es sieht nun nach sehr viel aus, ist es aber nicht und es lässt sich sogar automatisieren.

Fragen? Dann fragen!

TRIM für SSDs im ZFS Pool unter Linux aktivieren.

Speicherzellen eine SSD sind nicht unendlich beschreibbar. Irgendwann sind sie „kaputt“. Damit dieses möglichst spät passiert, hat jede SSD eine interne Logik, um Schreibzugriffe möglichst gut auf Speicherbereiche zu verteilen. Im optimalen Fall wird jeder Speicherbereich gleich oft zum Schreiben benutzt. Damit dieses möglichst gut funktioniert, muss die SSD wissen, welche Speicherbereiche wirklich frei sind. Diese Information kann die SSD fast nur vom Filesystem selbst bekommen. Damit die Info weitergeleitet wird, gibt es TRIM https://de.wikipedia.org/wiki/TRIM.

ZFS bietet diese Möglichkeit natürlich auch und dieses ebenfalls unter Linux. Im zpool nennt sich diese Option autotrim und um zu prüfen ob es aktiviert ist, hilft folgender Befehl:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  off        local
rpool  autotrim  off        local

Wie man sehen kann, gibt es die beiden ZFS Pools mit den Namen bpool und rpool. Auf beiden ist autotrim deaktiviert. Zum Aktivieren ist folgender Befehl nötig:

$ zpool set autotrim=on bpool
$ zpool set autotrim=on rpool

Wenn man nun prüft, ob es aktiviert ist:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  on        local
rpool  autotrim  on        local

Sollte man dieses bestätigt bekommen.

Einen kleinen Tipp habe ich darüber hinaus zusätzlich noch. Wenn eine SSD an den Strom angeschlossen wird, ohne dass ein „Computer“ angeschlossen ist, fallen viele SSD in eine Art Wartungs- / Reparaturmodus. Dann sortieren SSDs selbstständig ihre Speicherzellen um. Wenn also einmal etwas in den ersten Speicherbereich geschrieben wurde, ist dieses nicht gleichbedeutend, dass es für immer in nur diesem Bereich liegen bleibt. Im laufenden Betrieb wird dieses verschoben, wenn die SSD (wie beschrieben) nur am Strom angeschlossen ist forciert man dieses zusätzlich bei vielen SSDs. Einfach 2 / 3 Stunden „laufen“ lassen… Hin und wieder lassen sich über diesen Weg „tote“ SSDs wiederbeleben. Alles funktioniert natürlich mit TRIM viel besser 😀

Frage? Dann fragen..

Linux Mint 20.x Ubuntu-Basis mit ZFS root Pool und native Verschlüsselung

Zu ZFS und warum man es haben will, muss ich hier sicher nicht mehr viel schreiben. Ebenfalls wird sich niemand mehr die Frage stellen, warum man seine Festplatte verschlüsseln möchte.

ABER wenn man nun Linux, ZFS und Verschlüsselung kombinieren möchte, dann gibt es etwas, worüber es sich zu schreiben lohnt. Wie man nun also sehr einfach unter sein Linux Mint >= 20.x einen native encryptet zfs root pool bekommt, darum geht es hier.

Linux Mint bringt seit Version 20 bereits alles mit um dieses ohne besonderen Aufwand zu erledigen. Natürlich ging es bereits schon früher, nur war es dann fast nur über den Weg möglich, die Festplatte inkl. Grub vollständig von Hand vor und während der Installation selbst fertig zu machen. Dieses ist… Sagen wir mal… „Für den erweiterten Anwender schon fast nicht zu machen“.

Zurück zu Linux Mint 20.x!

Wie erwähnt bringt diese Version alles Nötige mit, nur der Installer ist noch nicht ganz so weit und man muss ihm mit zwei Kleinigkeiten unter die Arme greifen. Einmal muss man die nötigen Pakete im Live-System nachinstallieren. Also einfach die gewünschte Version von Linux mit downloaden und davon booten. Ist man im Live-System angekommen, öffnen man ein Terminal und wirft die Installation der Pakete mit folgendem Befehl an:

sudo aptitude -y install libzfs2linux zfs-initramfs zfsutils-linux zfs-zed

Möchte man nun einfach nur sein Linux Mint auf einem ZFS Pool installieren, ist man schon fertig. Einfach den Installer starten und beim Punkt, auf welche Festplatte man sein neues System installieren möchte auf Advanced features… klicken und unten auf EXPERIMENTAL: Erase disk and use ZFS. Fertig ist!

Möchte man noch seinen zroot Pool verschlüsseln fehlt noch die zweite Kleinigkeit. Da der Installer den Wunsch und somit ebenfalls das Kennwort zur Verschlüsselung des ZFS Pools nicht abfragt, muss man es dem Installer mitgeben, bevor er mit seiner Arbeit startet. Dazu bleibt man im Terminal und editiert das Installerscript wie folgt:

sudo vi /usr/share/ubiquity/zsys-setup

Hier sucht man nun die Sektion, in welcher es ums Anlegen der ZFS Pools geht ?zpool create wäre eine gute Suche 😉

Hat man dieses gefunden (derzeit sollte es genau zwei Mal im Installerscript auftauchen) setzt man einfach vor das zpool create des rpools ein:

echo 'SUPER-SECURE' | 

Die Hochkomma bleiben dabei stehen und ihr ersetzt SUPER-SECURE durch euer gewünschtes Kennwort, was sich natürlich schon jeder gedacht hat. Damit wird dem zpool create rpool später im Installationsprozess euer Kennwort übergeben.

Fehlen nur noch die Optionen beim Erstellen des Pools, damit er ihn auch verschlüsselt. Dafür bitte folgendes vor die Zeile -O mountpoint=/ -R „${target}“ rpool „${partrpool}“ eintragen:

-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O keyformat=passphrase \

Am Ende sieht der Ausschnitt also beispielhaft wie folgt aus:

echo 'Kennwort!' | zpool create -f \
        -o ashift=12 \
        -O compression=lz4 \
        -O acltype=posixacl \
        -O xattr=sa \
        -O relatime=on \
        -O normalization=formD \
        -O mountpoint=/ \
        -O canmount=off \
        -O dnodesize=auto \
        -O sync=disabled \
        -O encryption=aes-256-gcm \
        -O keylocation=prompt \
        -O keyformat=passphrase \
        -O mountpoint=/ -R "${target}" rpool "${partrpool}"

Das war es auch schon. Jetzt, wie gewohnt den Installer starten und schon wird man nach dem Reboot aufgefordert seinen ZFS Pool mit einem Kennwort zu entschlüsseln. Oh, geht natürlich so mit EFi und lagacy und überhaupt….

Ob alles so funktioniert hat, wie man es sich vorstellt, lässt sich direkt nach dem ersten Boot ins neue System prüfen. Einfach Terminal öffnen und mittels folgender Befehle prüfen, ob die Verschlüsselung aktiviert ist und sich auch sauber durch den Pool bis zu den Benutzerdaten weiter vererbt hat:

test@test-VirtualBox:~$ sudo zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1,38G  97,3M  1,28G        -         -     0%     6%  1.00x    ONLINE  -
rpool  26,5G  4,46G  22,0G        -         -     3%    16%  1.00x    ONLINE  -
test@test-VirtualBox:~$ sudo zpool get feature@encryption
NAME   PROPERTY            VALUE               SOURCE
bpool  feature@encryption  disabled            local
rpool  feature@encryption  active              local
test@test-VirtualBox:~$ sudo zfs get encryption rpool/USERDATA/test_9d9i92
NAME                        PROPERTY    VALUE        SOURCE
rpool/USERDATA/test_9d9i92  encryption  aes-256-gcm  -
test@test-VirtualBox:~$

Hier noch Bilder zum Klicken, das mögen ja viele.

Fragen? Dann fragen…

zfs send / recv schlägt mit „cannot receive incremental stream: destination […] has been modified“ fehl

Tach auch… Heute mal wieder etwas zum Thema ZFS (anscheinend wohl im Moment gefragt…)

Wenn man ZFS Volumes abgleichen möchte hilft einem bekanntermaßen ja zfs send / revc. Möchte man noch eine gewisse Historie am Ziel oder es handelt sich um recht große Volumes, dann freut man sich sehr über die Möglichkeit nur die Differenz zwischen zwei Snapshots abgleichen zu müssen.

Als kleines Beispiel:

Ich habe eine FreeBSD Jail für subsonic. In dieser liegen einfach die gesamten Mediafiles, was weiß ich.. Sagen wir mal 100GB. Vom Volume werden dann automatisch per zfsutils snapshots erstellt. Die wöchentlichen snapshots davon möchte ich nun gerne per SSH auf ein anderes System schieben, einfach um die Daten so „gesichert“ zu haben. Jedes System steht dann vielleicht noch in der Colocation in einem anderen DataCenter. Einmal die Woche 100GB abgleichen, das sind dann im Monat 400GB (ja, viel ist anders aber es ist ein reales Beispiel).

Initial pumpt das Skript nun also die 100GB rüber. Ich schreib mal den Befehl ohne Variablen zur besseren Lesbarkeit, ok?

zfssend@system01:~ # zfs send zroot/jails/subsonic@zfs-auto-snap_weekly-2015-06-14-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic

So jetzt habe ich also auf der zweiten Kiste eine 1a Kopie der Jail. Ab dem Moment muss ich nun nur noch die Differenz zum nächsten Snapshot übertragen mit einem:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic

Dieses funktioniert natürlich nur so lange die Daten im Ziel nicht verändert werden. Klar wie bei jeder Datensicherung die auf Inkrementen beruht. Ändere ich eines sind die nachfolgenden nicht mehr konsistent. Wie könnte nun so eine Änderung passieren? Ganz einfach ich renne in dem Filesystem herum und ändere Daten oder lege neue an. Was viele übersehen ist etwas wie atime. Also das einfache speichern der Information: Wann wurde die Datei zuletzt angefasst. Dieses würde schon als Änderung reichen um folgendes zu bekommen:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic
cannot receive incremental stream: destination zroot/backup/bsd02/subsonic has been modified
since most recent snapshot
warning: cannot send 'zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14': signal received

Und nun ist Essig mit der schönen Sicherung und man muss wieder Initial alles rüber schieben? Jain… Natürlich kann man dem zfs recv einfach mitteilen die Änderung zu ignorieren. Denn der snapshot ist dem Ziel ja bekannt. Also kann man dem Ziel sagen: der bestehende snapshot zählt, ignoriere als was danach passiert ist und gleiche das Delta zum aktuellen ab:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv -F zroot/backup/bsd02/subsonci

Ein -F ist hier also unser Freund. Hat man alles sauber geskriptet und ebenfalls nicht vergessen im Ziel hin und wieder die alten snapshots aufzuräumen, sollte man damit schon eine ganz brauchbare Datensicherheit haben!

Viel Spaß!

ZFS Snapshots

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!

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑