Was ist BTRFS

Weil ich mich gerade intensiv mit BTRFS beschäftige und dazu einige Recherchen durchführe, um für mich Licht in dieses Thema zu bringen, hier eine Auflistung meiner Funde, Erklärungen und Anleitungen. Wenn du Anmerkungen dazu hast, bin ich im Fediverse (About Seite) zu finden. Ansonsten hoffe ich wie immer, dass dieser Artikel dem einen oder der anderen hilft ebenfalls mehr Klarheit in das Thema zu bringen. Und … schreibt selbst mehr Blogartikel!

BTRFS steht für B-Tree File System und ist ein modernes Copy-on-Write-Dateisystem, das ursprünglich 2007 von Chris Mason bei Oracle entwickelt und 2009 in den Linux Kernel 2.6.29 aufgenommen wurde. Es wird heute von verschiedenen Distributionen und Unternehmen unterstützt, darunter Debian, SUSE, Red Hat, Fujitsu und Intel.

Der wesentliche Unterschied zu klassischen Dateisystemen wie ext4 oder NTFS besteht darin, dass BTRFS Daten nicht überschreibt. Wird eine Datei geändert, schreibt BTRFS die neue Version an eine andere Stelle, während die alte Version erhalten bleibt, bis sie nicht mehr benötigt wird.

Daraus ergeben sich mehrere Funktionen:

  • Snapshots: Momentaufnahmen des Dateisystems zu einem bestimmten Zeitpunkt, die anfangs kaum zusätzlichen Speicherplatz belegen.
  • Datenintegrität: BTRFS berechnet Prüfsummen für Daten und Metadaten. Fehler durch defekten RAM oder alternde Datenträger werden erkannt und können bei vorhandener Redundanz (z.B. RAID1) korrigiert werden.
  • Subvolumes: Das Dateisystem lässt sich in logische Teile gliedern, ähnlich Partitionen, aber flexibler.
  • Transparente Komprimierung: Daten können on-the-fly komprimiert werden (z.B. mit zstd).
  • Integrierte RAID-Unterstützung für RAID 0, 1, 10, 5 und 6.

Was sind Snapshots

Ein Snapshot ist eine Momentaufnahme des Dateisystems. Der aktuelle Zustand eines Ordners wird festgehalten und kann später wiederhergestellt werden.

Durch Copy-on-Write belegt ein frischer Snapshot zunächst kaum zusätzlichen Speicherplatz. Er verweist auf dieselben Datenblöcke wie das Original. Erst wenn Änderungen vorgenommen werden, entstehen neue Blöcke, während die alte Version im Snapshot erhalten bleibt. Der zusätzliche Platzverbrauch entspricht also der Differenz zwischen Original und Snapshot.

Daraus ergeben sich typische Einsatzbereiche:

  • Vor System-Updates: Snapshot anlegen, Update durchführen, bei Problemen zurückrollen.
  • Automatische Backups: Tools wie Snapper können in festen Intervallen Snapshots erstellen und alte automatisch löschen.
  • Experimente: Änderungen lassen sich testen und bei Bedarf vollständig rückgängig machen.

Wichtig: Ein Snapshot ist kein Backup. Bei einem Hardware-Ausfall sind Original und Snapshot verloren. Snapshots schützen vor logischen Fehlern wie fehlerhaften Updates oder versehentlichem Löschen, nicht vor Hardware-Ausfällen. Für echte Backups werden Snapshots mit btrfs send und btrfs receive auf ein anderes Medium übertragen.

Hinweise

Snapshots sind kein Ersatz für Backups. Einige Punkte sind zu beachten:

  • Platzverbrauch: Alte Snapshots können über die Zeit viel Platz belegen, da sie die Differenzen zu späteren Änderungen halten. Automatische Bereinigung ist daher sinnvoll.
  • Performance: Bei sehr großen Datenmengen oder Datenbanken kann Copy-on-Write bremsen. Für solche Fälle können Dateien oder Subvolumes mit dem nodatacow-Attribut markiert werden.
  • Kernel und Bootloader: Wird /boot in den Snapshot einbezogen, kann ein Rollback problematisch werden, wenn Kernel und Module nicht mehr zusammenpassen. Viele Distributionen schließen /boot daher aus oder behandeln den Kernel separat.

Snapshots mit btrfs “tool”

Snapshots lassen sich vollständig ohne zusätzliche Werkzeuge wie Snapper oder Timeshift erstellen und verwalten. Die notwendigen Befehle sind Teil von btrfs-progs, das auf jedem System mit Btrfs-Unterstützung vorhanden ist.

Snapshot erstellen

Ein Snapshot wird mit btrfs subvolume snapshot erstellt. Der Befehl benötigt ein Quell-Subvolume und ein Zielverzeichnis für den Snapshot.

Schreibgeschützter Snapshot (empfohlen für Backups):

sudo btrfs subvolume snapshot -r /home /snapshots/home/home_snapshot_$(date +%Y%m%d_%H%M%S)

Die Option -r erzeugt einen schreibgeschützten Snapshot. Dieser kann nicht versehentlich verändert werden und eignet sich für die spätere Übertragung mit btrfs send.

Schreibbarer Snapshot (für Tests oder Klone):

sudo btrfs subvolume snapshot /home /snapshots/home/home_snapshot_ro

Ohne -r entsteht ein beschreibbarer Snapshot, der wie eine vollständige Kopie des Dateisystems genutzt werden kann.

Wichtig: Snapshots können nur von Subvolumes erstellt werden, nicht von normalen Verzeichnissen. Wenn die Quelle kein Subvolume ist, gibt Btrfs einen Fehler zurück. Das Zielverzeichnis /snapshots/home/ muss dabei auf einem eigenen Subvolume liegen oder außerhalb des Quell-Subvolumes, damit keine rekursive Struktur entsteht.

Snapshot auflisten

Alle Subvolumes und Snapshots lassen sich mit folgendem Befehl anzeigen:

sudo btrfs subvolume list /

Die Ausgabe zeigt unter anderem die ID, die übergeordnete ID und den Pfad jedes Subvolumes. Mit der Option -s werden nur Snapshots aufgelistet, mit -r nur schreibgeschützte.

Eine typische Ausgabe von sudo btrfs subvolume list / sieht so aus:

ID 256 gen 12345 top level 5 path @
ID 257 gen 12340 top level 5 path @home
ID 258 gen 12200 top level 5 path @snapshots
ID 259 gen 12050 top level 5 path snapshots/home/home_snapshot_2026-03-14
ID 260 gen 11980 top level 5 path snapshots/home/home_snapshot_ro

Die Spalten im Einzelnen:

  • ID: Die eindeutige Nummer des Subvolumes. Diese wird intern von Btrfs verwendet und ist nicht mit der Snapshot-Nummer von Snapper zu verwechseln.
  • gen: Die Generation, also ein Zähler, der bei jeder Transaktion im Dateisystem erhöht wird. Ein höherer Wert bedeutet, dass das Subvolume später zuletzt geändert wurde.
  • top level: Die ID des übergeordneten Subvolumes. Der Wert 5 steht für das Top-Level-Subvolume, also die Wurzel des Btrfs-Dateisystems.
  • path: Der Pfad des Subvolumes relativ zum Top-Level-Subvolume. Hier wird sichtbar, wo das Subvolume im Baum hängt.

In diesem Beispiel erkennt man:

  • @ ist das Root-Subvolume (ID 256).
  • @home ist ein separates Subvolume für /home (ID 257).
  • @snapshots ist ein eigenes Subvolume (ID 258).
  • snapshots/home/home_snapshot_2026-03-14 und snapshots/home/home_snapshot_ro sind die Snapshots, die unter dem Pfad /snapshots/home/ angelegt wurden.

Hinweis: Die Ausgabe zeigt die Pfade relativ zum Top-Level-Subvolume, nicht relativ zum gemounteten Root. Wenn /snapshots als separates Subvolume eingebunden ist, erscheint der Snapshot-Pfad entsprechend unter snapshots/home/.... Wird /snapshots nicht separat gemountet, liegen die Snapshots innerhalb des Root-Subvolumes und tauchen als @/snapshots/home/... auf.

Mit der Option -s werden nur Snapshots angezeigt:

sudo btrfs subvolume list -s /

Mit der Option -r nur schreibgeschützte Subvolumes:

sudo btrfs subvolume list -r /

Mit der Option -t wird zusätzlich die Art des Subvolumes ausgegeben (snapshot oder subvolume):

sudo btrfs subvolume list -t /

Snapshot löschen

Ein Snapshot wird nicht mit rm -rf entfernt, sondern mit:

sudo btrfs subvolume delete /snapshots/home/home_snapshot_ro

Das entsprechende Verzeichnis wird sofort entfernt, die eigentlichen Datenblöcke werden jedoch im Hintergrund gelöscht. Der Befehl kehrt sofort zurück, ohne auf den Abschluss der Datenlöschung zu warten.

Soll gewartet werden, bis die Löschung vollständig abgeschlossen ist:

sudo btrfs subvolume sync /snapshots/home

Snapshot zurückrollen

Für das Zurückrollen auf einen Snapshot wird das aktuelle Subvolume verschoben und der Snapshot an seine Stelle kopiert:

## Aktuelles Subvolume als Backup umbenennen
sudo mv /mnt/btrfs_root/@home /mnt/btrfs_root/@home_backup_$(date +%Y%m%d)

## Snapshot als neues Subvolume kopieren
sudo btrfs subvolume snapshot \
  /snapshots/home/home_snapshot_20260301 \
  /mnt/btrfs_root/@home

Nach einem erneuten Einbinden steht der wiederhergestellte Zustand zur Verfügung. Der alte Zustand bleibt unter @home_backup_... erhalten, bis er manuell gelöscht wird.

Snapshots sichern mit send/receive

Für echte Backups außerhalb des Systems dienen btrfs send und btrfs receive. Beide Operationen erfordern schreibgeschützte Snapshots.

Initiales Backup:

sudo btrfs send /snapshots/home/home_snapshot_ro | btrfs receive /backupvol

Inkrementelles Backup (nur Änderungen seit dem letzten Snapshot):

sudo btrfs send -p /snapshots/home/home_snapshot_ro /snapshots/home/home_snapshot_20260314 | btrfs receive /backupvol

Die Option -p gibt den vorherigen Snapshot als Parent an. Übertragen werden nur die Differenzen zwischen beiden Snapshots.

@snapshots anlegen, konfigurieren und verwenden

Der Speicherort für Snapshots wird im Btrfs-Subvolume-Layout und in /etc/fstab festgelegt, nicht in Snappers Konfigurationsdatei. In Snappers Konfiguration gibt SUBVOLUME lediglich an, für welches Verzeichnis Snapshots erstellt werden sollen (z. B. /). Ob die Snapshots im selben Subvolume verbleiben oder ausgelagert werden, entscheidet die Konfiguration über die Btrfs-Subvolume-Struktur und die Mount-Einträge in /etc/fstab.

In der Snapper Konfiguration wird Bezug auf die @snapshots Definitionen in der /etc/fstab genommen.

Btrfs-Optionsliste

subvol=NAME / subvolid=ID Legt fest, welches Subvolume unter dem Einhängepunkt erscheint. subvol=@ mountet das Subvolume @ als Root. Ohne diese Option wird das Standard-Subvolume verwendet .

compress=TYPE / compress-force=TYPE Aktiviert transparente Kompression. Mögliche Typen: zlib (Standard), lzo, zstd. compress-force komprimiert auch schlecht komprimierbare Dateien. Wichtig: Komprimierung ist mit nodatacow unvereinbar – bei aktivem nodatacow wird compress ignoriert .

nodatacow Deaktiviert Copy-on-Write für das gesamte Dateisystem. Wichtig: Diese Option wirkt sich auf das ganze Dateisystem aus, nicht nur auf ein Subvolume. Nur die Optionen des zuerst gemounteten Subvolumes sind wirksam . nodatacow impliziert nodatasum – es werden keine Prüfsummen mehr berechnet .

nodatasum Deaktiviert Prüfsummen für Daten. Wird automatisch bei nodatacow aktiviert .

autodefrag / noautodefrag Aktiviert automatische Defragmentierung bei kleinen, zufälligen Schreibvorgängen. Nicht geeignet für Datenbanken oder VM-Images . Warnung: Kann bei Snapshots/Reflinks die Extent-Freigabe zerstören und den Speicherverbrauch stark erhöhen .

commit=SECONDS Setzt das Intervall für periodische Commits. Standard: 30 Sekunden. Höhere Werte verzögern das Schreiben auf persistente Speicherung – bei Systemabsturz gehen mehr Daten verloren .

ssd / nossd Teilt dem Dateisystem mit, dass es auf einem SSD läuft. Btrfs optimiert dann die Block-Allokation. Auf modernen Kerneln oft automatisch erkannt .

discard / nodiscard / discard=async discard aktiviert synchrones TRIM bei jedem Löschen – kann die Performance beeinträchtigen. discard=async (seit Kernel 5.6) sammelt freigegebene Blöcke und führt TRIM asynchron aus – die bevorzugte Methode. Alternativ: nodiscard und periodisches fstrim .

space_cache / space_cache=v1 / space_cache=v2 / nospace_cache Steuert den Free-Space-Cache. v2 (Standard seit Kernel 4.5) ist für große Dateisysteme deutlich performanter. nospace_cache deaktiviert den Cache .

acl / noacl Aktiviert/deaktiviert POSIX ACLs. Standard: acl .

barrier / nobarrier barrier (Standard) stellt sicher, dass I/O-Operationen durch den Geräte-Cache gehen und persistent gespeichert werden. nobarrier kann die Performance erhöhen, führt bei Stromausfall aber mit Sicherheit zu Datenverlust .

degraded Erlaubt das Mounten mit fehlenden Geräten (z. B. bei RAID). Ein Read-Write-Mount kann fehlschlagen, wenn zu viele Geräte fehlen .

skip_balance Überspringt die automatische Wiederaufnahme einer unterbrochenen Balance-Operation .

Optionen für spezielle Einsatzzwecke

Swapfile auf Btrfs Ein Swapfile muss folgende Bedingungen erfüllen :

  • Muss vorgelagert (preallocated) sein, keine Holes
  • Muss NODATACOW sein (impliziert NODATASUM) - mehr im nächsten Kapitel
  • Keine Kompression
  • Das enthaltende Subvolume darf nicht snapshottet werden, solange das Swapfile aktiv ist
  • Nur ein einziges Gerät und ein einziges Datenprofil

Beispiel für ein Swap-Subvolume in der fstab:

UUID=... /swap btrfs subvol=@swap,nodatacow,noatime 0 0

/etc/stab Praktisches Beispiel

Hier eine Beispiel fstab mit den wichtigsten Optionen.

## <file system>                 <mount point>   <type>  <options>                                                           <dump>  <pass>
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /               btrfs   subvol=@,compress=zstd:3,noatime,ssd,discard=async,space_cache=v2   0       1
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /home           btrfs   subvol=@home,compress=zstd:3,noatime,ssd,discard=async,space_cache=v2  0       2
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /.snapshots     btrfs   subvol=@snapshots,noatime,ssd,space_cache=v2                        0       0

Kritische Einschränkungen zu nodatacow und compress

  1. Optionen gelten für das gesamte Dateisystem: nodatacow, nodatasum und compress können nicht pro Subvolume über Mount-Optionen gesteuert werden. Nur die Optionen des ersten gemounteten Subvolumes zählen .

  2. chattr +C - Um Copy-on-Write nur für bestimmte Daten zu deaktivieren, ohne das gesamte Dateisystem zu beeinträchtigen, ist das Setzen des C-Attributs auf Datei- oder Verzeichnisebene der richtige Weg

  3. nodatacow + compress schließen sich aus: Wird nodatacow gesetzt, ist Kompression automatisch deaktiviert .

  4. nodatacow und Snapshots: Snapshots funktionieren weiterhin, aber beim ersten Schreiben nach einem Snapshot wird CoW erzwungen, um die alten Blöcke zu bewahren. Der Vorteil von nodatacow ist damit eingeschränkt .

  5. nodatacow entfernt Datenintegrität: Ohne nodatasum gibt es keine Prüfsummen. Auf Multi-Disk-Systemen (RAID1) kann nach einem Absturz nicht festgestellt werden, welche Kopie korrekt ist – mit etwa 50% Wahrscheinlichkeit wird die beschädigte Kopie gelesen .

  6. autodefrag bei Snapshots vermeiden: Auto-Defragmentierung bricht Reflink- und Snapshot-Verbindungen auf und kann den Speicherverbrauch erheblich steigern .

chattr +C statt nodatacow

Um Copy-on-Write nur für bestimmte Daten (z. B. VM-Images oder Datenbanken) zu deaktivieren, ohne das gesamte Dateisystem zu beeinträchtigen, ist das Setzen des C-Attributs auf Datei- oder Verzeichnisebene der richtige Weg

## Neues, leeres Verzeichnis erstellen (oder ein bestehendes umbenennen)
sudo mkdir /var/lib/libvirt/images_nocow
sudo chattr +C /var/lib/libvirt/images_nocow

Alle neu erstellten Dateien in diesem Verzeichnis erben das NOCOW-Attribut

Für bereits existierende Dateien ist ein Workaround nötig:

# Verzeichnis umbenennen, neu erstellen, Attribut setzen, Daten zurückkopieren
sudo mv /var/lib/libvirt/images /var/lib/libvirt/images_old
sudo mkdir /var/lib/libvirt/images
sudo chattr +C /var/lib/libvirt/images
sudo cp -a --reflink=never /var/lib/libvirt/images_old/. /var/lib/libvirt/images/
sudo rm -rf /var/lib/libvirt/images_old

Der Parameter --reflink=never ist entscheidend, da cp sonst standardmäßig eine CoW-Kopie (Reflink) erstellt, die das Attribut nicht übernimmt.

Wichtige Einschränkung: Snapshots

Auch mit chattr +C gibt es eine Einschränkung: Wenn ein Snapshot erstellt wird, bricht dieser die NOCOW-Eigenschaft teilweise auf. Beim ersten Schreiben in eine Datei nach einem Snapshot wird CoW erzwungen, um die alten Blöcke für den Snapshot zu bewahren. Danach greift wieder NOCOW, bis der nächste Snapshot erstellt wird.

Für VM-Images oder Datenbanken, die von Snapshots ausgeschlossen werden sollen, empfiehlt es sich daher, sie in eine eigene Partition mit mit nodatacow oder eventuell anderem Dateisystem anzulegen.

Das Standard-Layout bei Manjaro

Manjaro legt bei der automatischen Partitionierung eine große Btrfs-Partition mit mehreren Subvolumes an. Die Namenskonvention beginnt traditionell mit einem @-Zeichen.

Obwohl die genauen Namen je nach Installer-Version variieren können, entspricht das typische Layout dem, was auch in der Manjaro-Wiki als Konvention beschrieben wird:

  • @: Das Root-Dateisystem (/).
  • @home: Das Verzeichnis für Benutzerdaten (/home).
  • @snapshots (optional): In der Wiki wird dieses Subvolume als Beispiel für einen möglichen Snapshot-Speicherort erwähnt, aber es ist nicht Teil der Standard-Installation.

Das bedeutet: Bei einer Standard-Manjaro-Installation liegen alle Snapshots, die du beispielsweise mit Timeshift oder Snapper erstellst, standardmäßig innerhalb des @-Subvolumes unter /.snapshots. Ein separates Subvolume für Snapshots wird nicht erstellt.

Das Standard-Layout bei TUXEDO OS (Debian-Basis)

TUXEDO OS nutzt Btrfs und Snapper standardmäßig, um automatische Snapshots vor und nach Paket-Updates zu erstellen.

TUXEDO gibt an, dass bei der Installation sechs Subvolumes angelegt werden, die als getrennte Namensräume innerhalb einer Btrfs-Partition fungieren. Die genauen Namen dieser sechs Subvolumes werden in der offiziellen Ankündigung jedoch nicht explizit aufgeführt.

Was aus den offiziellen TUXEDO-Dokumenten bekannt ist:

  • Snapper ist vorkonfiguriert und erstellt automatisch Snapshots.
  • Ein grafisches Tool namens Btrfs Assistant ist installiert, um Subvolumes und Snapshots zu verwalten.
  • Der erste Snapshot wird bereits beim ersten Bootvorgang erstellt und als „Factory Image“ bezeichnet.

Automatisierung ohne externe Tools

Für regelmäßige Snapshots genügt ein Eintrag in der Crontab. Ein einfaches Shell-Skript erstellt einen zeitgestempelten Snapshot:

#!/bin/bash
NOW=$(date +"%Y-%m-%d_%H:%M:%S")
mkdir -p /snapshots/home
sudo btrfs subvolume snapshot -r /home "/snapshots/home/home_snapshot_${NOW}"

Dieses Skript kann per cron oder systemd-timer in festen Intervallen ausgeführt werden.

  • Snapshots sind keine Backups. Sie liegen auf demselben Dateisystem. Bei einem Hardware-Ausfall sind Original und Snapshot verloren. Für echte Backups müssen Snapshots auf ein anderes Medium übertragen werden, etwa mit btrfs send.
  • Alte Snapshots regelmäßig löschen. Snapshots belegen Speicherplatz, auch wenn sie anfangs kaum zusätzlichen Platz benötigen. Mit der Zeit sammeln sich Differenzen an. Ein regelmäßiges Aufräumen ist notwendig.
  • Nested Subvolumes beachten. Wenn ein Subvolume ein anderes Subvolume enthält, wird dieses beim Snapshot nicht mitgesichert. Der Verzeichniseintrag bleibt leer. Für vollständige Sicherungen müssen verschachtelte Subvolumes separat behandelt werden.

Tool: Snapper - Snapshotverwaltung

Snapper ist ein Werkzeug zur Verwaltung von Dateisystem-Snapshots unter Linux. Es wurde ursprünglich von SUSE entwickelt und ist heute in vielen Distributionen verfügbar.

Snapper automatisiert das Erstellen, Verwalten und Bereinigen von BTRFS-Snapshots. Es legt Snapshots manuell, oder auch automatisch bei Paket-Updates oder auch zeitgesteuert an.

List

Mit snapper geht es komfortabler. Snapshots auflisten mit

snapper list

Eine typische Ausgabe von snapper list sieht so aus:

 # | Typ   | Vor # | Datum                        | Benutzer | Bereinigung | Beschreibung
---+-------+-------+------------------------------+----------+-------------+---------------------------
 0 | single|       |                              | root     |             | current
 1 | single|       | 2026-09-20 08:15:03 +0200    | root     | timeline    | timeline
 2 | pre   |       | 2026-09-22 19:40:11 +0200    | root     | number      | zypp(packagekitd)
 3 | post  |     2 | 2026-09-22 19:41:57 +0200    | root     | number      | zypp(packagekitd)
 4 | single|       | 2026-09-23 03:00:01 +0200    | root     | timeline    | timeline
 5 | pre   |       | 2026-09-25 14:02:33 +0200    | root     | number      | zypp(zypper)
 6 | post  |     5 | 2026-09-25 14:03:12 +0200    | root     | number      | zypp(zypper)

Die Spalten im Einzelnen:

  • #: Die Nummer des Snapshots. Diese wird für snapper delete, snapper diff oder snapper undochange verwendet.
  • Typ: single für eigenständige Snapshots, pre und post für Paare vor und nach einer Änderung.
  • Vor #: Bei einem post-Snapshot die Nummer des zugehörigen pre-Snapshots. Bei single und pre bleibt die Spalte leer.
  • Datum: Zeitpunkt der Erstellung.
  • Benutzer: Der Benutzer, der den Snapshot ausgelöst hat (meist root).
  • Bereinigung: Die Cleanup-Strategie. timeline für zeitgesteuerte Snapshots, number für eine feste Anzahl, empty-pre-post für verwaiste Paare.
  • Beschreibung: Freitext, bei Paketoperationen etwa zypp(zypper) oder zypp(packagekitd).

An diesem Beispiel sieht man auch, warum Pre/Post-Paare gemeinsam gelöscht werden sollten: Snapshot 5 und 6 gehören zusammen, ebenso 2 und 3. Ein snapper delete 5-6 entfernt das Paar 5 und 6, ein snapper delete 2-3 entsprechend das Paar 2 und 3.

Änderungen - diff

Um Änderungen zwischen zwei Snapshots zu sehen, dient snapper diff:

sudo snapper -c root diff 1..3

Die Ausgabe zeigt, welche Dateien zwischen den Snapshots hinzugefügt, gelöscht oder geändert wurden.

Löschen

Bei Verwendung von snapper erfolgt das Löschen über:

sudo snapper -c root delete NUMBER

Dabei ist NUMBER die Nummer des Snapshots aus snapper list. Automatisch erstellte Pre/Post-Paare – etwa vor und nach einem Paket-Update – sollten immer gemeinsam gelöscht werden, da sie zusammengehören. Snapper kann das mit einem Befehl erledigen:

sudo snapper -c root delete NUMBER1-NUMBER2

Damit werden beide Snapshots des Paares in einem Schritt entfernt.

Lösch Strategie

Es gibt Situationen, in denen nur der post-Snapshot entfernt wird, während der pre-Snapshot erhalten bleibt. Sinnvoll ist das zum Beispiel, wenn:

  • Der Pre-Snapshot als Rollback-Punkt dienen soll: Vor einem Update wird ein pre-Snapshot angelegt. Nach dem Update wird der post-Snapshot normalerweise nur zur Dokumentation der Änderungen benötigt. Will man den Rollback-Punkt behalten, aber die Vergleichsbasis nicht mehr, löscht man nur den post.
  • Speicherplatz knapp wird: Der pre-Snapshot markiert den Zustand vor der Änderung und ist damit der eigentlich wertvolle. Der post-Snapshot ist oft entbehrlich, wenn die Änderung erfolgreich war.
  • Snapper bei number-Cleanup nicht greift: Snapper löscht bei der Cleanup-Strategie number bevorzugt ganze Paare. Bleibt ein einzelner Snapshot übrig – etwa weil der pre manuell als schützenswert markiert wurde – muss der post unter Umständen manuell entfernt werden.

In der Praxis ist das Löschen nur des post-Snapshots eher die Ausnahme. Üblich ist, dass beide gemeinsam entfernt werden, weil der pre-Snapshot ohne zugehörigen post bei der Bereinigung als verwaist gilt und dann über die Strategie empty-pre-post automatisch entfernt wird.

Zurückrollen

Snapper bietet zwei Varianten:

  1. Einzelne Dateien wiederherstellen: Mit snapper undochange werden Änderungen zwischen zwei Snapshots rückgängig gemacht. Die Snapshots selbst liegen unter /.snapshots/NUMBER/snapshot/ und können auch direkt eingesehen werden.
  2. Komplettes System zurückrollen: Mit snapper rollback wird das Root-Subvolume auf einen früheren Snapshot zurückgesetzt. Voraussetzung ist, dass zuvor in den gewünschten Snapshot gebootet wurde.

Wiederherstellen einzelne Dateien

Ein Snapshot verhält sich wie ein normales Verzeichnis. Bei Verwendung von Snapper liegen die Snapshots unter /.snapshots/NUMBER/snapshot/:

##### Snapshot-Inhalt ansehen
ls /.snapshots/5/snapshot/home/hoergen/

##### Einzelne Datei aus dem Snapshot zurückkopieren
sudo cp /.snapshots/5/snapshot/home/hoergen/.bashrc /home/hoergen/.bashrc

Alternativ kann snapper undochange verwendet werden, um Änderungen zwischen zwei Snapshots rückgängig zu machen:

##### Änderungen zwischen Snapshot 5 (pre) und 6 (post) rückgängig machen
sudo snapper -c root undochange 5..6

Sollen nur bestimmte Dateien zurückgesetzt werden, können diese explizit angegeben werden:

sudo snapper -c root undochange 5..6 /etc/fstab /etc/default/grub

Komplettes System wiederherstellen - Rollback

Für das vollständige Zurückrollen des Root-Dateisystems bietet Snapper den Befehl snapper rollback. Voraussetzung ist, dass das System zuvor in den gewünschten Snapshot gebootet wurde. Dies geschieht über das Boot-Menü, das Snapper zusammen mit grub-btrfs bereitstellt. Im GRUB-Menü erscheint ein Eintrag „BTRFS Snapshots", aus dem ein beliebiger Snapshot als Root-Subvolume gebootet werden kann.

Nach dem Booten in den Snapshot ist das Dateisystem schreibgeschützt eingebunden. Der Rollback wird dann mit folgendem Befehl ausgeführt:

sudo snapper rollback

Optional mit Beschreibung:

sudo snapper rollback -d "Rollback nach fehlerhaftem Update"

Snapper erstellt dabei automatisch einen Snapshot des Zustands vor dem Rollback. Nach einem Neustart ist das System auf dem Stand des gewählten Snapshots.

Wichtig: snapper rollback funktioniert nur für das Root-Subvolume /. Andere Subvolumes wie /home werden nicht mit zurückgesetzt.

Automatisierung mit Snapper

Manuelles Erstellen von Snapshots ist auf Dauer unpraktisch. Snapper kann automatisch Timeline-Snapshots anlegen (z.B. stündlich, täglich, wöchentlich) und alte nach definierten Regeln löschen, damit der Speicherplatz nicht vollläuft.

Typische Konfiguration unter /etc/snapper/configs/root:

TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_LIMIT_HOURLY="6"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_MONTHLY="6"
TIMELINE_LIMIT_YEARLY="2"
FREE_LIMIT="0.2"    # Mindestens 20% frei lassen

Aktivierung der Timer:

sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer

Damit laufen die automatischen Snapshots und die Bereinigung. Vor einem pacman -Syu oder apt upgrade kann zusätzlich ein manueller Snapshot mit Beschreibung angelegt werden:

sudo snapper -c root create --description "vor dem Update"

Nach dem Update lässt sich mit snapper diff nachvollziehen, was sich geändert hat. Bei Bedarf kann zurückgerollt werden.

Tool: grub-btrfs

grub-btrfs ist ein eigenständiges Tool, das die von Snapper erstellten Snapshots in das GRUB-Menü einbindet. Nach der Installation erscheint im GRUB-Menü ein Eintrag „BTRFS Snapshots", aus dem heraus ein beliebiger Snapshot als Root-Subvolume gebootet werden kann. Dies ist die Voraussetzung für den Rollback mit snapper rollback.

Defragmentierung: Möglichkeiten und Probleme

Der Befehl btrfs filesystem defragment ermöglicht die Defragmentierung von Dateien und Verzeichnis-Metadaten im laufenden Betrieb.

Die Anwendung ist jedoch mit erheblichen Einschränkungen verbunden, insbesondere beim Einsatz von Snapshots oder Reflink-Kopien.

Ein Reflink (kurz für „Reference Link“) ist eine spezielle Art von Dateikopie, die moderne Dateisysteme wie Btrfs oder XFS unterstützen. Sie nutzt das Copy-on-Write-Prinzip (CoW), um eine Kopie zu erstellen, die zunächst keinen zusätzlichen Speicherplatz belegt und nahezu augenblicklich fertig ist

Fragmentierung prüfen

Bevor eine Defragmentierung durchgeführt wird, sollte geprüft werden, ob überhaupt eine relevante Fragmentierung vorliegt. Btrfs meldet Fragmentierung nicht automatisch. Der zuverlässigste Weg ist die Messung der Extents pro Datei mit filefrag sowie die Beobachtung des tatsächlichen Performance-Verhaltens.

Es gibt keine Möglichkeit ein ganzes Volume zu prüfen. Es geht nur über filefrag

Ein ganzes Btrfs-Volume lässt sich nicht direkt als Ganzes auf seinen Fragmentierungsgrad prüfen. Es gibt keinen Befehl, der eine einzelne Zahl oder einen Prozentsatz für die Fragmentierung des gesamten Dateisystems ausgibt.

Der Grund liegt in der Arbeitsweise von Btrfs. Fragmentierung ist ein Zustand, der sich auf einzelne Dateien bezieht, nicht auf das Volume als Ganzes. Ein Volume kann Tausende von Dateien enthalten, von denen einige stark fragmentiert und andere gar nicht fragmentiert sind. Es gibt keine sinnvolle einzelne Kennzahl, die das zusammenfassen würde.

Es gibt einen indirekten Ansatz über den Speicherverbrauch. Wenn btrfs filesystem df eine große Diskrepanz zwischen Size (allokierter Platz) und Used (tatsächlich belegter Platz) zeigt, deutet das auf fragmentierte oder verwaiste Extents hin. Das ist aber keine Messung der Fragmentierung, sondern eine Reaktion auf eine vermutete Ursache.

Fragmentierung einzelner Dateien messen

filefrag ist Teil des Pakets e2fsprogs und funktioniert dank FIEMAP-Unterstützung auch auf Btrfs. Eine Datei mit einem einzigen Extent ist nicht fragmentiert; je mehr Extents, desto stärker die Fragmentierung.

## Fragmentierung einer einzelnen Datei prüfen
filefrag /home/hoergen/.bashrc

Beispielausgabe:

/home/hoergen/.bashrc: 3 extents found

Die am stärksten fragmentierten Dateien finden

Für einen Überblick über ein Verzeichnis kann die Ausgabe sortiert werden. Die Zahl der Extents steht in der zweiten Spalte:

## Top 10 der fragmentiertesten Dateien im aktuellen Verzeichnis
filefrag * | sort -nr -k 2 | head -10

sort -nr -k 2 die Zeilen also nach der Extent-Anzahl, absteigend, mit der höchsten Zahl oben.

  • -n: Numerische Sortierung. Ohne diese Option würde sort alphabetisch sortieren, sodass z. B. 10 vor 2 käme. Mit -n wird der Zahlenwert interpretiert.

  • -r: Umgekehrte Reihenfolge (reverse). Statt aufsteigend wird absteigend sortiert, also die größte Zahl zuerst.

  • -k 2: Sortierschlüssel ist die zweite Spalte. Standardmäßig trennt sort Spalten an Leerzeichen. In der Ausgabe von filefrag ist die zweite Spalte die Anzahl der Extents.

  • head -10 gibt standardmäßig die ersten zehn Zeilen der Eingabe aus. Da die Eingabe zuvor absteigend nach Extent-Anzahl sortiert wurde, stehen hier die zehn am stärksten fragmentierten Dateien des Verzeichnisses.

Für das Home-Verzeichnis entsprechend:

## Top 10 der fragmentiertesten Dateien in /home/hoergen
cd /home/hoergen
filefrag * | sort -nr -k 2 | head -10

Für Snapshots unter /snapshots/home/... ist eine Prüfung nur dann sinnvoll, wenn dort tatsächlich Dateien liegen, die stark verändert wurden. Da Snapshots in der Regel schreibgeschützt sind, ändert sich ihre Fragmentierung nach der Erstellung nicht mehr.

Typische Kandidaten prüfen

Bestimmte Verzeichnisse neigen aufgrund ihres Nutzungsmusters stärker zur Fragmentierung und eventuell mount Option nodatacow in Betracht ziehen

## Log-Verzeichnis prüfen
filefrag /var/log/journal/* | sort -nr -k 2 | head -10

## Temporäres Verzeichnis prüfen
filefrag /tmp/* 2>/dev/null | sort -nr -k 2 | head -10

Performance als eigentlicher Indikator

Die reine Extent-Zahl sagt noch nichts über die tatsächliche Leistung aus. Eine Defragmentierung ist erst dann sinnvoll, wenn eine spürbare Verlangsamung auftritt. Beispiele:

  • Eine Datenbank unter /home/hoergen/db/ reagiert merklich langsamer bei Abfragen.
  • Eine Logdatei unter /var/log/ verlangsamt den Systemstart.

Ohne solche wahrnehmbaren Effekte überwiegen bei Systemen mit Snapshots die Risiken der Defragmentierung (Verlust der Extent-Freigabe, erhöhter Speicherverbrauch) den Nutzen.

Bevor eine Datei defragmentiert wird, sollte geprüft werden, ob sie mit einem Snapshot oder einer Reflink-Kopie verbunden ist. Ist das der Fall, bricht eine Defragmentierung diese Verbindung auf und der Speicherverbrauch steigt. Eine gezielte Prüfung, ob eine Datei mit einem Snapshot geteilt wird, ist mit Bordmitteln nicht direkt möglich. In der Praxis bedeutet das: Dateien, die in den üblichen Snapshot-Pfaden wie /snapshots/home/... oder /.snapshots/NUMBER/snapshot/ enthalten sind, sollten nicht defragmentiert werden.

Möglichkeiten der Defragmentierung

Defragmentierung kann die I/O-Performance verbessern, indem fragmentierte Dateien in zusammenhängende Blöcke umgeschrieben werden. Der Befehl unterstützt verschiedene Optionen:

## Einzelne Datei defragmentieren
sudo btrfs filesystem defragment /pfad/zur/datei

## Verzeichnis rekursiv defragmentieren
sudo btrfs filesystem defragment -r /pfad/zum/verzeichnis

## Mit Kompression (zstd, zlib oder lzo)
sudo btrfs filesystem defragment -r -czstd /pfad

Wichtig: Ohne die Option -r werden nur Metadaten defragmentiert, nicht die Dateiinhalte . Für eine vollständige Dateisystem-Defragmentierung ist -r erforderlich.

Automatische Defragmentierung (autodefrag)

Die Mount-Option autodefrag aktiviert eine Online-Defragmentierung, die bei kleinen, zufälligen Schreibvorgängen automatisch eingreift . Diese Option eignet sich für Desktop-Systeme mit normaler Nutzung, wird aber nicht für große Datenbanken oder VM-Images empfohlen .

Aktivierung in /etc/fstab:

UUID=... / btrfs defaults,autodefrag,compress=zstd 0 0

Das zentrale Problem: Verlust der Extent-Freigabe

Der kritischste Nachteil betrifft Systeme mit Snapshots oder Reflink-Kopien. Die offizielle Btrfs-Dokumentation stellt klar fest:

Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.

Was das konkret bedeutet:

Wenn eine Datei defragmentiert wird, die gerade von einem Snapshot oder einem Reflink-Klon mitbenutzt wird, bricht der Befehl diese gemeinsame Nutzung auf. Er erstellt eine neue, private Kopie der Daten für die defragmentierte Datei, während der Snapshot weiterhin auf die alten Datenblöcke verweist. Da beide Kopien nun separat existieren, verdoppelt sich der Speicherplatzbedarf für diese Daten .

Ein Beispiel: Bei einem System mit Snapper, das stündliche Snapshots erstellt, kann eine Defragmentierung von / dazu führen, dass der Speicherverbrauch drastisch ansteigt, weil jede defragmentierte Datei ihre Verbindung zu allen bestehenden Snapshots verliert .

Defrag - Fazit

AspektBewertung
Performance-GewinnMöglich bei fragmentierten Dateien ohne Snapshots
SpeicherplatzErhöht sich bei Snapshots/Reflinks durch Verlust der Extent-Freigabe
Snapshot-KompatibilitätNicht gegeben – Snapshots verlieren ihre COW-Verbindung
EmpfehlungNur für Dateien ohne Snapshot-Bezug; bei Snapper-Systemen vermeiden

Für Systeme mit Snapper oder Timeshift gilt: Defragmentierung sollte vermieden werden, es sei denn, sie wird gezielt auf Dateien angewendet, die nachweislich nicht in Snapshots enthalten sind. Der Speicherplatzgewinn durch Snapshots wiegt den Performance-Verlust durch Fragmentierung in den meisten Fällen auf.

Defragmentieren mit Vorteilen & Risiko - Backup

Um dann doch defragmentieren zu können, wenn es wirklich notwendig sein sollte, wäre eine nicht wirklich komplett durchdachte Idee

  1. ein Backup zu erstellen
  2. danach alle Snapshots zu löschen
  3. defragmentieren
  4. neue Snapshots zu erstellen
  5. nochmal ein Backup erstellen

Fazit & Best Practice

BTRFS mit Snapshots ist eine praktische Möglichkeit, Systemänderungen abzusichern. Die manuellen Befehle sind überschaubar, und mit Snapper lässt sich der Prozess automatisieren. Für Systeme, auf denen häufig Updates oder Experimente durchgeführt werden, ist das eine sinnvolle Einrichtung. Ein Umstieg von ext4 ist nicht trivial, aber bei einer Neuinstallation oder einem Zweitsystem eine Überlegung wert.

Best Practice

  1. Standard-Layout mit @ und @home (oder wie vom Installer vorgegeben)
  2. Snapper für automatische Snapshots verwenden
  3. Vor kritischen Aktionen manuell einen Snapshot anlegen
  4. grub-btrfs installieren für snapper rollback, weil es die Snapshots ins GRUB-Menü einbindet.
  5. fstab-Optionen sparsam setzen
  6. Geschwindigkeit: Aktuelle Performancetests zeigen, dass BTRFS mit XFS, ext4 und anderen noch nicht mithalten kann, aka teilweise extrem langsamer ist. Wer Performance braucht, sollte aktuell auf ein anderes FS setzen.

Vorsicht

  1. nodatacow global setzen
  2. autodefrag in der fstab
  3. Defragmentierung auf Systemen mit Snapshots

Quellen

Offizielle Btrfs-Dokumentation

Snapper-Dokumentation

Distributionen und Praxisanleitungen