Btrfs Snapshots und Subvolumes: Copy on Write Dateisysteme praktisch nutzen

1. Warum Copy on Write das Volume Management verändert

Klassische Dateisysteme wie ext4 überschreiben Datenblöcke beim Speichern direkt an derselben Stelle, was Snapshots technisch aufwendig macht und meist eine zusätzliche Schicht wie LVM erfordert. Btrfs geht einen anderen Weg: Jede Änderung an einem Block wird als neue Kopie geschrieben, während der alte Block so lange erhalten bleibt, wie noch ein Verweis darauf existiert. Genau dieses Prinzip macht Snapshots auf Btrfs so billig, dass sie sich problemlos vor jedem Paketupdate oder Deployment erstellen lassen.

Subvolumes sind dabei kein Ersatz für Partitionen, sondern eigenständige, benannte Dateibäume innerhalb eines einzigen Btrfs Dateisystems, die sich unabhängig voneinander mounten, snapshotten und löschen lassen. Ein typisches Server Layout legt für root, für home und für Datenbankverzeichnisse jeweils eigene Subvolumes an, sodass ein Snapshot von root nicht versehentlich Terabytes an Nutzdaten mit einfriert, die ohnehin über ein eigenes Backup Konzept laufen.

2. Subvolumes anlegen und verstehen

Ein neues Subvolume entsteht mit einem einzigen Befehl und verhält sich danach wie ein normales Verzeichnis, wird intern aber als eigener B Baum mit eigener Baum ID verwaltet. Diese Eigenständigkeit ist der Grund, warum sich ein Subvolume gezielt mounten, unmounten oder als Standard Subvolume für den gesamten Dateisystem Mount festlegen lässt, was viele Distributionen für das root Subvolume nutzen.

Wichtig für die Praxis: Ein Subvolume teilt sich den freien Speicherplatz mit allen anderen Subvolumes im selben Dateisystem, es gibt also keine feste Größenzuweisung wie bei einer klassischen Partition, sofern keine Quotas gesetzt sind. Das erleichtert die Planung erheblich, weil Speicherplatz nicht vorab auf einzelne Bereiche aufgeteilt werden muss und stattdessen dynamisch dort verbraucht wird, wo er tatsächlich benötigt wird.

# Neues Subvolume für MySQL Datenverzeichnis anlegen
btrfs subvolume create /mnt/data/mysql

# Alle Subvolumes im Dateisystem auflisten
btrfs subvolume list /mnt/data

# Details zu einem einzelnen Subvolume anzeigen, inkl. UUID und Elternbezug
btrfs subvolume show /mnt/data/mysql

3. Snapshots erstellen: read only gegenüber read write

Ein Snapshot ist technisch nichts anderes als ein weiteres Subvolume, dessen Dateibaum zum Zeitpunkt der Erstellung exakt dem Quell Subvolume entspricht, ohne dass dabei ein einziges Datenblock kopiert wird. Erst wenn eine Datei im Original oder im Snapshot geändert wird, greift Copy on Write und schreibt den geänderten Block neu, während der alte Block im jeweils anderen Subvolume unverändert sichtbar bleibt.

Für Rollback Zwecke sind read only Snapshots die richtige Wahl, weil sie garantieren, dass der eingefrorene Zustand nicht versehentlich verändert wird, während read write Snapshots sich eignen, wenn direkt im Snapshot weitergearbeitet werden soll, etwa um eine Konfiguration testweise zu ändern, ohne das Original zu berühren.

# Read only Snapshot des root Subvolumes erstellen
btrfs subvolume snapshot -r / /.snapshots/root-2026-08-08

# Read write Snapshot für testweise Änderungen erstellen
btrfs subvolume snapshot / /.snapshots/root-testing

# Pruefen, ob ein Subvolume read only ist
btrfs property get /.snapshots/root-2026-08-08 ro

4. Praxisfall: Rollback vor riskanten Deployments

Vor jedem größeren Magento Deployment, Kernel Update oder Paket Upgrade lohnt sich ein read only Snapshot des betroffenen Subvolumes als letzte Absicherung. Schlägt das Deployment fehl oder verhält sich der Server danach unerwartet, lässt sich der alte Zustand ohne aufwendige Restore Prozedur wiederherstellen, weil der Snapshot bereits vollständig auf der Platte liegt und nicht erst aus einem Backup Archiv entpackt werden muss.

Der eigentliche Rollback erfolgt, indem das aktuelle Subvolume umbenannt oder gelöscht und der Snapshot an dessen Stelle als beschreibbares Subvolume eingesetzt wird. Bei einem root Subvolume, das per Bootloader referenziert wird, reicht dafür oft ein Eintrag in der Bootloader Konfiguration, der auf die Snapshot Subvolume ID verweist, sodass ein Neustart genügt, um den vorherigen Stand zu laden.

# Aktuelles, fehlerhaftes Subvolume zur Seite legen
mv /mnt/data/mysql /mnt/data/mysql-broken

# Snapshot als beschreibbares Subvolume an dessen Stelle setzen
btrfs subvolume snapshot /.snapshots/mysql-pre-deploy /mnt/data/mysql

# Nach erfolgreicher Pruefung das defekte Subvolume endgueltig entfernen
btrfs subvolume delete /mnt/data/mysql-broken

5. Wichtige btrfs Kommandos für den Alltag

Neben Erstellung und Löschung von Subvolumes gehören einige weitere Kommandos in das Standardrepertoire jedes Btrfs Administrators. Der Aufruf btrfs filesystem show gibt einen Überblick über alle beteiligten Geräte eines Dateisystems, während btrfs filesystem usage eine deutlich genauere Aufschlüsselung von belegtem, freiem und allokiertem Speicherplatz liefert als das klassische df.

Ein gelöschtes Subvolume verschwindet nicht sofort, sondern wird zunächst als verwaist markiert und im Hintergrund vom Cleaner Thread des Kernels entfernt, was bei sehr großen Snapshots einige Minuten dauern kann und in Skripten berücksichtigt werden sollte, wenn direkt danach auf frei gewordenen Speicherplatz gezählt wird.

# Geraete und Groessen eines Btrfs Dateisystems anzeigen
btrfs filesystem show /mnt/data

# Detaillierte Speicherplatz Aufschluesselung, inkl. Allokation
btrfs filesystem usage /mnt/data

# Laufende Loeschvorgaenge von Subvolumes im Hintergrund pruefen
btrfs subvolume sync /mnt/data

6. Speicherplatz und CoW: Was ein Snapshot wirklich kostet

Direkt nach der Erstellung kostet ein Snapshot praktisch keinen zusätzlichen Speicherplatz, weil er sich vollständig alle Datenblöcke mit dem Original teilt. Der tatsächliche Verbrauch wächst erst mit der Zeit, und zwar proportional zur Menge der Blöcke, die im Original oder im Snapshot seit der Erstellung verändert wurden, weshalb ein Snapshot auf einem stark schreibintensiven Datenbankverzeichnis deutlich schneller Speicherplatz bindet als auf einem eher statischen Konfigurationsverzeichnis.

Das klassische du Kommando ist für die Bewertung dieses Overheads ungeeignet, weil es jede Datei einzeln zählt, ohne zu berücksichtigen, dass sich viele Blöcke mehrere Subvolumes teilen. Verlässlicher ist ein Blick auf die qgroup Statistiken, die exklusiv belegten Speicherplatz pro Subvolume von gemeinsam genutztem Speicherplatz trennen und damit eine realistischere Einschätzung liefern, wie viel Platz eine Löschung tatsächlich freigeben würde.

# Quota Gruppen aktivieren, um exklusiven vs. geteilten Speicherplatz zu sehen
btrfs quota enable /mnt/data

# Exklusiv belegten und geteilten Speicherplatz pro Subvolume anzeigen
btrfs qgroup show -pcre /mnt/data

7. Snapshots automatisieren statt manuell zu pflegen

Manuell erstellte Snapshots vor einem Deployment sind sinnvoll, ersetzen aber keine regelmäßige Snapshot Strategie für den laufenden Betrieb. Werkzeuge wie snapper übernehmen die zeitgesteuerte Erstellung und vor allem das Aufräumen alter Snapshots nach konfigurierbaren Aufbewahrungsregeln, sodass die Anzahl stündlicher, täglicher und wöchentlicher Snapshots nicht unkontrolliert wächst und den verfügbaren Speicherplatz aufzehrt.

Wer auf zusätzliche Werkzeuge verzichten möchte, erreicht mit einem einfachen Cron Job und einem Skript, das nach jeder Snapshot Erstellung ältere Snapshots anhand ihres Zeitstempels löscht, einen vergleichbaren Effekt. Wichtig ist in beiden Fällen, dass die Bereinigung genauso zuverlässig läuft wie die Erstellung, denn eine unbegrenzt wachsende Anzahl an Snapshots verlangsamt Operationen wie btrfs balance spürbar.

#!/usr/bin/env bash
# scripts/btrfs-snapshot-rotate.sh: taeglichen Snapshot anlegen, alte entfernen
set -euo pipefail

TS=$(date +%Y-%m-%d)
btrfs subvolume snapshot -r /mnt/data/mysql /.snapshots/mysql-$TS

# Snapshots aelter als 7 Tage entfernen
find /.snapshots -maxdepth 1 -name 'mysql-*' -mtime +7 \
  -exec btrfs subvolume delete {} \;

8. Best Practices für ein sinnvolles Subvolume Layout

Ein durchdachtes Layout trennt Bereiche, die tatsächlich von Snapshots profitieren, von Bereichen, die bewusst davon ausgenommen werden sollten. Das root Subvolume, Konfigurationsverzeichnisse und Anwendungscode gehören klassischerweise in den Snapshot Bereich, während Log Verzeichnisse und temporäre Daten häufig als separate Subvolumes ohne regelmäßige Snapshots geführt werden, weil sie sich ständig ändern und den Snapshot Overhead unnötig erhöhen.

Datenbankverzeichnisse verdienen besondere Aufmerksamkeit: MySQL und ähnliche Systeme schreiben viele kleine, wahllos verteilte Änderungen, was auf einem Copy on Write Dateisystem zu Fragmentierung führt. Für solche Verzeichnisse empfiehlt sich das Attribut nodatacow, das Copy on Write für einzelne Dateien oder Verzeichnisse deaktiviert und damit die Fragmentierung deutlich reduziert, allerdings auf Kosten der Prüfsummen und der Snapshot Effizienz für genau diesen Bereich.

9. Typische Fallstricke im produktiven Einsatz

Der wichtigste Grundsatz zuerst: Ein Snapshot ist kein Backup, solange er auf demselben physischen Datenträger liegt. Ein Festplattenausfall vernichtet Original und Snapshot gleichermaßen, weshalb Snapshots immer als Ergänzung zu einer echten Offsite Sicherung zu verstehen sind, nicht als deren Ersatz.

Ein weiterer Fallstrick betrifft nodatacow in Kombination mit Snapshots: Sobald ein Snapshot von einer Datei mit diesem Attribut existiert, greift für den nächsten Schreibzugriff trotzdem einmalig Copy on Write, weil der Snapshot sonst inkonsistent würde. Wer nodatacow für Datenbankdateien nutzt, sollte das Attribut deshalb vor dem ersten Schreibzugriff setzen, am besten direkt beim Anlegen des Verzeichnisses, und nicht nachträglich auf bereits gefüllte Datenbankdateien anwenden.

10. Zusammenfassung

11. FAQ: Btrfs Snapshots