Arch auf BtrFS

Diese Seite stellt einen groben Überblick zum Dateisystem Btrfs dar und erläutert was beachtet werden muss um Arch auf Btrfs zu installieren.

Warnung: Btrfs befindet sich noch in der Entwicklung. Einige Funktionen weisen daher noch Fehler auf. Detailliertere Auskunft gibt das (englischsprachige) Btrfs Wiki Status, Is Btrfs stable? und Getting started.

Was ist BtrFS

Btrfs (B-tree file system) ist ein Copy-on-Write (CoW; engl. wörtlich "Kopieren beim Schreiben") Dateisystem. Copy-on-Write Dateisystem schreiben bei Kopien Daten erst dann auf die Festplatte, wenn die Kopie gegenüber dem Orginal verändert wurde.

Eine Btrfs-Partition stellt ein Volumen dar, welches weiter in Subvolumen unterteilt werden kann. Subvolumen stehen in ihren Eigenschaften zwischen Partitionen und Ordnern. Im Gegensatz zu Partitionen haben Subvolumen keine festgelegte Größe sondern verhalten sich wie Ordner (theoretisch können Subvolumen mit Quotas belegt werden, welche einer Maximalgröße gleich kämen, allerdings wird noch darüber gestritten wie stabil die Funktion von Btrfs ist). Im Verzeichnisbaum erscheinen und verhalten sich Subvolumen eines eingehängten Btrfs-Volumens als Ordner und müssen nicht extra eingehängt werden. In Ubuntu-Derivaten und OpenSUSE hat es sich eingebürgert Top-Level-Subvolumen mit einem vorangestellten @ zu benennen. Subvolumen verhalten sich wie Ordner und bedürfen keiner speziellen Nomenklatur. Jede Subvolumen das anders heißt als was das System erwartet muss explizit eingehängt werden.

Btrfs erlaubt es spezielle Subvolumen, sogenante Snapshots (engl. "Momentaufnahmen") zu erstellen. Ein Snapshot kopiert ein Volumen, nicht jedoch die darin enthaltenen Subvolumen (und damit auch keine darin enthaltenen Snapshots). Da Snapshots Momentaufnahmen von Volumen darstellen, können vorherige Zustände einfach und ohne viel Aufwand wieder her gestellt werden. Es ist jedoch wichtig zu beachten, dass Snapshots keine Sicherungskopien im Sinne von Backups sind und daher zwar gegen fehlerhafte Updates oder versehentlich überschriebene/gelöschte Dateien helfen, nicht jedoch gegen Festplattenschäden.

Btrfs unterstützt RAIDS und kann diese im Betriev vergrößern, verkleinern und zwischen verschiedenen RAID Typen konvertieren. Warnung: Die RAID 5 und RAID 6 Implementation ist fehlerbehaftet und anfällig für Datenverlust. Von der Verwendung von RAID56 mit Btrfs ist daher dringend abzuraten! aktuelle Informationen sind im offizielle Btrfs wiki (englisch) zu finden the Btrfs page on RAID5 and RAID6 for status updates.

Installation von Arch Linux auf Btrfs

Die die Installation verläuft bis auf wenige ausnahmen wie auf anderen Dateisystemen.

Partitionierung der Festplatte

Es empfiehlt sich eine Partition für Btrfs anzulegen. eine partitionslose Installation bei der das Dateisystem direkt auf die Festplatte (z.B. /dev/sda statt /dev/sda1) geschrieben wird ist zwar möglich, kommt aber mit diversen Einschränkungen. Gründe die Gegen eine partitionslose Btrfs Festplatte sprechen:

• Auf UEFI Systemen ist eine EFI Partition notwendig
• bios/GTP Setups benötigt GRUB eine BIOS BOOT Partition
• Btrfs unterstützt keine Swap-Dateien und benötigt eine Swap-Partition

Im Falle dass kein Swap benötigt wird, mit Bios/MBR gearbeitet wird und sonstig auch keine anderen Partitionen vorgesehen sind ist partitionslos zwar generell möglich, aber meistens nicht empfehlenswert. Es bringt keinen Vorteil gegenüber einer einzelnen Partition welche die gesamte Festplatte vereinnahmt und würde nur zu unnötiger Verwirrung führen.

Nehmen wir ein System mit zwei SSD-Festplatten mit je einer, die gesamte Platte einnehmende Btrfs Partition, an. Auf /dev/sda soll Arch Linux und vllt noch etwas langweiliges wie Debian installiert werden, auf /dev/sdb sollen die Daten der Benutzer liegen.

Sobald die Partition(en) angelegt ist/sind. Können die für btrfs vorgesehenen Partitionen mit mkfs.btrfs formatiert werden.

# mkfs.btrfs -L "btrfs_pool" /dev/sda1
# mkfs.btrfs -L "btrfs_pool" /dev/sdb1

Anschließend sollen nun verschiedene Subvolumen angelegt werden. Das Subvolumen eines Btrfs Volumens automatisch eingehängt werden ist hier gleichzeitig Fluch als auch Segen. Es gilt unbedingt zu vermeiden, dass das Oberste Volumen (auch Btrfs Pool genannt), welches durch die Formatierung der Partition als Btrfs angelegt wurde, dauerhaft eingehängt ist. Wäre dies der Fall, wären auch alle untergeordneten Snapshots lesbar und damit auch alle Dateien, deren Zugriffsrechte zwischenzeitlich verschärft wurden. Es empfiehlt sich daher alles, auch das Wurzelverzeichnis von Arch Linux als Subvolumen des Btrfs Pools anzulegen. Damit ein Snapshot dazu verwendet werden kann das System zu einem vorherigen, funktionalen Zustand zurück zu rollen sollte das gesamte Wurzelverzeichnis von Arch Linux in einem Subvolumen enthalten sein. Entgegen weit verbreiteter Annahme ist das Verzeichnis /var nicht unnötig sondern enthält z.B. den Ordner /var/lib in welchem pacman Informationen über die installierten Pakete speichert. Lediglich Ordner wie /var/cache, /var/log, /var/spool und /var/temp können im Bezug auf Snapshots als unnötiges Gerümpel angesehen werden. Für diese bieten sich daher eigene Subvolumen an, welche durch die Funktionsweise von Snapshots automatisch ignoriert werden. Das home Verzeichnis von Root (/root) wird in den meisten Fällen auch nicht benötigt, da dort im Idealfall keine wichtigen Daten liegen sollten (man vergleiche e mit der Besenkammer des Hausmeisters). Aus anderen Gründen verhält es sich ähnlich mit dem Verzeichnis für Services (/srv) welches ebenfalls als dem Snapshot ausgeschlossen werden kann (für Heimsysteme ist /srv meistens ohnehin leer).

# mkdir /mnt/arch
# mount -o rw,noatime,compress=lzo /dev/sda1 /mnt/arch

# btrfs subvol create /mnt/arch/arch
# btrfs subvol create /mnt/arch/root
# btrfs subvol create /mnt/arch/srv

# mkdir /mnt/arch/root/arch_pool
# mkdir /mnt/arch/root/home_pool
# mkdir /mnt/arch/snapshots
# mkdir /mnt/arch/arch/var

# btrfs subvol create /mnt/arch/var/cache
# btrfs subvol create /mnt/arch/var/log
# btrfs subvol create /mnt/arch/var/spool
# btrfs subvol create /mnt/arch/var/temp

# mkdir /mnt/arch/home
# mount -o rw,noatime,compress=lzo /dev/sdb1 /mnt/arch/home
# mkdir /mnt/arch/home/snapshots

# btrfs subvol create /mnt/arch/home/BENUTZERNAME
# btrfs subvol create /mnt/arch/home/BENUTZERNAME/Dokumente
# btrfs subvol create /mnt/arch/home/BENUTZERNAME/Downloads
# btrfs subvol create /mnt/arch/home/BENUTZERNAME/Musik
# btrfs subvol create /mnt/arch/home/BENUTZERNAME/Bilder
# btrfs subvol cr... usw. usf.

Die Snapshots Ordner werden später zur Ablage der Snapshots benutzt. Das Wurzeldatesystem wird beim Subvolumen arch eingehängt. Alle untergeordneten Subvolumen sind automatisch eingehängt und, wenn man sich den Unfug mit dem @ gespart hat, auch an der richtigen Stelle. Die beiden Ordner im /root Verzeichnis sind später für die Snapshots relevant. Für die Benutzerdaten wurde je ein Subvolumen per Benutzer erstellt und mit den Typischen Ordnern bevölkert. Dieser wird unter/home/BENUTZERNAME eingehängt. Dies hat den Vorteil, dass man die Ordner mit den Eigentlichen Benutzerdaten (Dokumente, Musik, Videos) auch in z.B. Debian einhängen könnte (hier aber unter /home/BENUTZERNAME/ORDNER) ohne dass man sich sorgen machen muss, dass sich die Konfigurationsdateien der verschiedenen Programmversionen in verschiedenen Betriebssysteme gegenseitig überschreiben und unbrauchbar machen. Debian könnte hier gleich dem Subvolumen arch mit einem Subvolumen linux_museum unt entsprechenden untergeordneten Subvolumen angelegt werden.

Weitere Installation

Bis zum Schritt pacstrap folgt alles weiter der Arch Linux Installationsanleitung. beim pacstrap Schritt sollte das Paket btrfs-progs mit installiert werden, da dieses nicht in er base Gruppe enthalten ist.

fstab bearbeiten

Leider verwirrt Btrfs den Script der die fstab generiert etwas und einige Angaben finden sich doppelt (subvol=/arch,subvol=arch z.B. ist ein klassischer Fehler). Zudem sollten wir die btrfs Pools ebenfalls in der fstab aufführen aber nicht automatisch einhängen.

Die fstab sollte in etwas so aussehen:

# <file system> <dir> <type> <options> <dump> <pass>
# root file system   /dev/sda1
UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...compress=lzo
UUID=... /root btrfs rw,ssd,discard,noatime,subvol=root,subvolid=...compress=lzo
UUID=... /srv btrfs rw,ssd,discard,noatime,subvol=srv,subvolid=...compress=lzo

# user home directories /dev/sdb1
UUID=... /home/BENUTZERNAME btrfs rw,ssd,discard,noatime,subvol=BENUTZERNAME,subvolid=...compress=lzo

# btrfs-top-levels
UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,subvol=arch,subvolid=...compress=lzo
UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,subvol=arch,subvolid=...compress=lzo

Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit:

# btrfs subvol list /

Die Datenkompression ist ein Performance boost for Copy-on-Write zu lasten der CPU. Der Overhead ist allerdings vernachlässigbar gering. lzo ist ein auf Geschwindigkeit optimierter Algorithmus. Btrfs kennt noch einen langsamen aber effizienteren Kompressionsalgorithmus und den effektiven und schnellen zstd. Benutzt man zstd kann GRUB das System nicht booten. Natürlich könnte man /boot auf eine eigene Partition auslagern und jedes einzeln per snapshot sichern, aber das ist den Aufwand nicht Wert, wenn man das Risiko bedenkt es mal zu vergessen. noatime ist notwendig, da Copy-on-Write sonst auch bei Dateizugriffen eine Änderung der Kopie erkennen und daher schreiben würde. SSD werden von btrfs automatisch erkannt. Die Angaben ssd und discard und daher eher redundant, mount mag es aber, wenn redundante Angaben explizit angegeben werden. Ob man discard verwenden will ist einem selbst überlassen, die Meinungen gehen hierzu auseinander. Näheres im Artikel über SSD Festplatten.

Installation zu Ende führen und Bootloader installieren

Die Installation folgt nun gänzlich der Standard Installations Anleitung. Als Bootloader empfielt sich GRUB. Alle anderen funktionieren mit Btrfs nicht oder nur mit schweren Einschränkungen (keine Kompression, keine RAIDS, etc.).

Snapshots erstellen

Einen Snapshot des gesamten System zu erstellen ist erfrischend einfach:

# mount /root/arch_pool
# btrfs subvol snapshot /root/arch_pool/arch /root/arch_pool/snapshots/arch_ZEITSTEMPEL
# umount /root/arch_pool

Der Snapshots enthält da gesamte Wurzeldateisystem mit ausnahme der Subvolumen /root, /srv, /var/cache, /var/log, /var/spool und /var/temp. ein gut zum sortieren geeigneter Zeitstempel (Jahr_Monat_Tag_Sekunden-seit-Mitternacht) lässt sich wie folgt erstellen:

$ echo $(date +%y_%m_%d)__$(( $(date +%s)-$(date -d 'today 0' +%s) ))

Echte Backups mit Btrfs erstellen

Btrfs stellt die Werkzeuge send und receive zur Verfügung: btrfs send sendet ein Volumen an die Standardausgabe (stout) und btrfs receive erstellt aus einem mit btrfs send gesendetem Volumen ein neues Subvolumen. Hiermit lassen sich ein echte Backup erzeugen. Zuerst wird ein Snapshot des zu sichernden Volumens erstellt und mit btrfs send/receive ans Ziellaufwerk gesendet. Für alle weiteren Backups des selben Volumens wird ein neuer Snapshot erstellt und nur die Differenz zwischen diesem und dem Vorherigen an das Ziellaufwerk gesendet. Hierdurch ist lediglich das initiale Backup zeitaufwendig, alle weiteren jedoch wesentlich schneller als z.B. rsync. Marc Merlin hat dies als Bash-Script automatisiert und beschreibt diesen Ausführlich in seine Blog (englisch) Doing fast incremental backups with btrfs send and receive.