Was sind ZFS-Snapshots?
ZFS arbeitet mit Copy-on-Write — jede Änderung wird an eine neue Stelle geschrieben, die alten Blöcke bleiben erhalten. Ein Snapshot friert diesen Stand ein: Die Blöcke werden einfach nicht mehr zum Überschreiben freigegeben. Deshalb ist ein Snapshot schneller erstellt als eine Datei gespeichert — er kostet nur so viel Platz, wie sich danach ändert.
Was man damit machen kann:
- Einzelne Dateien aus dem Snapshot herauskopieren
- Das gesamte Dataset auf den Snapshot-Stand zurückrollen
- Einen beschreibbaren Clone aus dem Snapshot erstellen
- Den Snapshot (oder nur die Differenz zum nächsten) per SSH auf ein anderes System replizieren
Snapshot erstellen und nutzen
Dataset mit Testdaten vorbereiten:
zfs create rpool/testdaten dd if=/dev/zero of=/rpool/testdaten/image01.img bs=10240 count=10240 # 100 MB zfs list rpool/testdaten NAME USED AVAIL REFER MOUNTPOINT rpool/testdaten 100M 9,02G 100M /rpool/testdaten
Snapshot erstellen — der Name nach dem @ ist frei wählbar:
zfs snapshot rpool/testdaten@vor-aenderung
Auf den Snapshot zugreifen — das versteckte Verzeichnis .zfs taucht nicht in ls auf, ist aber direkt erreichbar:
ls /rpool/testdaten/.zfs/snapshot/ vor-aenderung ls /rpool/testdaten/.zfs/snapshot/vor-aenderung/ image01.img
Von hier aus lassen sich versehentlich gelöschte Dateien einfach zurückkopieren. Um das gesamte Dataset auf den Snapshot-Stand zurückzurollen:
zfs rollback rpool/testdaten@vor-aenderung
Snapshot per SSH replizieren
Mit zfs send und zfs recv lässt sich ein Snapshot auf ein anderes System schieben — ein Einzeiler:
zfs send rpool/testdaten@vor-aenderung \ | ssh root@backup-server zfs recv backup/testdaten@vor-aenderung
Danach muss nur noch die Differenz zwischen zwei Snapshots übertragen werden — bei 1 GB Änderungen auf einem 100 GB Dataset werden auch nur 1 GB übertragen. Alle ZFS-Properties (NFS-Shares, SMB-Shares, Quotas) wandern mit. Mehr dazu im Beitrag zur ZFS-Datensicherung und zur Fehlerbehebung bei zfs send/recv.
Time Slider und Boot Environments
Unter OpenIndiana/Solaris gibt es den Time Slider — ein Nautilus-Plugin, das automatisch Snapshots erstellt und eine grafische Zeitleiste bietet. Alte Snapshots werden automatisch aufgeräumt wenn die Platte voll wird.
Noch mächtiger sind Boot Environments (beadm). Vor einem Systemupdate wird automatisch ein Snapshot des Root-Pools erstellt und davon ein Clone gebootet. Geht beim Update etwas schief, bootet man einfach das alte Environment — kein Stress, kein Ausfall:
beadm list BE Active Mountpoint Space Policy Created openindiana NR / 11,6G static 2011-09-28 19:06 openindiana-1 - - 37,3M static 2011-10-27 20:04 # Neues Boot Environment anlegen beadm create vor-experiment
Für automatisierte Snapshots unter FreeBSD siehe automatische ZFS-Snapshots mit zfs-auto-snapshot. Fragen? Einfach melden.
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.