Open Source-Software findet in immer mehr Unternehmen und Behörden ihren Einsatz. Im Juli widmet IT-Administrator daher seinen Heftschwerpunkt der quelloffenen ... (mehr)

Snapshot vom Root-Dateisystem

Snapper soll vor allem Snapshots des kompletten Systems erstellen. Wenn Sie ein aktuelles Suse-System mit Yast auf eine Btrfs-Partition installiert haben, existiert dort automatisch schon eine Standardkonfiguration namens "root". Sie bezieht sich immer auf das Subvolume mit dem Root-Dateisystem. Wenn Sie Snapper auf einer anderen Distribution nachinstalliert haben, können Sie die "root"-Konfiguration mit folgendem Befehl anlegen:

snapper create-config /

Wenn Sie den Parameter "-c" weglassen, gilt der entsprechende Befehl immer für die Standardkonfiguration. Wenn Sie also "snapper list" aufrufen, zeigt Ihnen Snapper alle Snapshots für die Konfiguration "root" und somit des Systems an. Auf einem aktuellen Suse-System sollten dabei wie in Bild 2 bereits mehrere Snapshots zu sehen sein.

Bild 2: Auf diesem System mit openSUSE 13.2 haben Yast und Zypper bereits ein paar Aktualisierungen durchgeführt und dabei entsprechende Snapshots angelegt.

Analog erstellen Sie mit »snapper create« schnell einen Schnappschuss des kompletten Systems. Unter openSUSE gibt es dabei aber eine kleine Stolperfalle: Yast legt bei der Installation mehrere Subvolumes an, unter anderem für »/var/log« . Die Inhalte dieser Subvolumes bleiben daher bei einem Aufruf von "snapper create" außen vor. Das ist pure Absicht: Würde man zu einem älteren Snapshot zurückkehren, würde Snapper dabei auch die Log-Dateien überschreiben, was wiederum nach Meinung der Suse-Entwickler die Fehlersuche erschwert. Wenn Sie auch Snapshots für »/var/log« erstellen möchten, müssen Sie folglich für dieses Subvolume selbst eine eigene Konfiguration erstellen. Sofern Sie mit "-c" eine ganz bestimmte Konfiguration auswählen, muss das "-c" übrigens immer direkt hinter "snapper" folgen, also beispielsweise »snapper -c home list« (und nicht »snapper list -c home« ).

Buchführung über Snapshots

Die per "snapper create" angelegten Snapshots kennzeichnet die von "snapper list" ausgegebene Tabelle mit einem "single" in der Spalte "Typ". Snapper kennt aber noch zwei weitere Typen: Yast und Zypper legen automatisch einen Snapshot an, bevor sie eine Änderung am System durchführen. Diese Snapshots tragen in der Spalte "Typ" die Bezeichnung "pre". Sobald Yast respektive Zypper die Software installiert oder Einstellungen geändert haben, erzeugen sie direkt einen zweiten Snapshot. Dieser trägt in der Spalte "Typ" die Bezeichnung "post".

Gleichzeitig merkt sich Snapper, welcher (Pre-)Snapshot vorausgegangen ist. In der Spalte "Vorher #" können Sie ablesen, zu welchem Pre-Snapshot ein Post-Snapshot gehört. In Bild 2 hat beispielsweise Zypper zunächst den Snapshot mit der Nummer 2 erstellt, dann irgendetwas installiert und anschließend den Snapshot mit der Nummer 3 angelegt. Durch diese Zusatzinformationen können Sie und Snapper nachvollziehen, welche Änderungen Yast und Zypper im Einzelnen durchgeführt haben. Sie dürfen natürlich auch selbst Pre- und Post-Snapshots anlegen. Das übernimmt der folgende Befehl:

snapper create --description "Benutzer Tux angelegt" --command "useradd tux -m -p 123456"

Mit ihm erstellt Snapper zunächst einen Pre-Snapshot, führt dann das Kommando »useradd tux -m -p 123456« aus und legt schließlich einen Post-Snapshot an. Bei den mit "single" gekennzeichneten Snap­shots merkt sich Snapper keinerlei Verwandtschaftsbeziehung.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2020