KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

Snapshots mal anders

Das Besondere an Btrfs-Snapshots ist, dass sie quasi umsonst mitgeliefert werden und dadurch sehr effizient sind. Snapshots in Btrfs verbrauchen auch zu Beginn ihres Lebens keinerlei Platz, es muss nicht wie bei LVM-Snapshots ein bestimmter Teil der Festplatte gleich zugewiesen werden. Dementsprechend können Btrfs-Snapshots auch nicht überlaufen, weil zur Erstellung zu wenig vorallokiert und zu spät an ein Vergrößern gedacht wurde. Diese Filesystem Snapshots eröffnen ein weites Spektrum an Anwendungsmöglichkeiten, da im Gegensatz zu LVM-Snapshots keine (teils dramatischen) Geschwindigkeitseinbußen bei der Verwendung von vielen Snapshots zu erwarten sind. Eine Limitierung der Anzahl an Snapshots gibt es wie bei Subvolumes praktisch nicht.

Wie die nahe Verwandtschaft mit Subvolumes erahnen lässt, sind Snapshots auch über dieselbe Kommando-Gruppe zu erstellen. Folgendes Beispiel legt einen neuen Snapshot des Top-Level Volumes an und verschiebt anschließend eine Datei aus dem Top-Level in das zuvor erzeugte Subvolume. Der Snapshot konserviert wie gewünscht den Datenstand zum Zeitpunkt seiner Erstellung. Wie auf jedes andere Subvolume kann auf einen Snapshot direkt über den Verzeichnisnamen zugegriffen werden, ihn extra einzuhängen, ist nicht notwendig (siehe Abbildung 7).

Snapshots verwenden

Nach dem Verschieben einer 3 GByte großen Datei in ein Subvolume zeigt ein »du« des Top-Level Volumes wie erwartet nur mehr 13 GByte statt 16 GByte an. Der Snapshot weist noch immer die 16 GByte aus und das Subvolume »subvol_test« nur 3 GByte. Ein »df« weist auf die 3 GByte extra Bedarf des Snapshots hin.

Welchen Namen ein Snapshot bekommt, ist prinzipiell frei wählbar, ein aussagekräftiges Namensschema aber sehr empfehlenswert. Man erkennt mit dem extra Schalter »-p« für »btrfs subvolume list« das Parent-Subvolume, von dem ein Subvolume abstammt. Es ist aber nicht möglich, einen Snapshot von einem Subvolume zu unterscheiden, und es ist auch nicht direkt erkennbar, wann der Snapshot erstellt wurde. Dass es möglich ist, auch Snapshots von Snapshots beliebiger Tiefe zu machen, vereinfacht das Ganze nicht wirklich, sie stammen nämlich alle vom selben Eltern-Volume ab. Hier gibt es noch Aufholbedarf hinsichtlich einfacherer Administration. Genug Platz für das Speichern der Deltas zwischen den Subvolumes vorausgesetzt kann beispielsweise ganz einfach mittels Cron-Job stündlich ein Snapshot eines Subvolumes (etwa des Home-Verzeichnisses) erstellt und alte Snapshots automatisch gelöscht werden. Auf Wunsch können Snapshots auch nur read-only, rein für Backup-Zwecke erzeugt werden. Ein Backup des Dateisystems auf unabhängige Datenträger ersetzen Snapshots aber nicht. Sie sind an das Top-Level-Subvolume und damit an dieselben Festplatten gebunden. Da Snapshots nicht rekursiv sind, kann ganz gezielt für Unterverzeichnisse mit stark variablen Inhalten – zum Beispiel ein »/var/log« - oder ein »/var/spool« -Verzeichnis – ein eigenes Subvolume erzeugt werden, um es von einem Snapshot eines darüber liegenden Verzeichnisses auszunehmen. Das kann viel Platz während der Lebenszeit eines Snapshots sparen.

Ä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 /2019