Arch auf BtrFS: Unterschied zwischen den Versionen
Hint für die Ermittlung und Verwendung der UUIDs. |
|||
| (6 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 19: | Zeile 19: | ||
Es empfiehlt sich eine Partition für BtrFS anzulegen. Eine partitionslose Installation bei der das Dateisystem direkt auf die Festplatte (z.B. {{ic|/dev/sda}} statt {{ic|/dev/sda1}}) geschrieben wird ist zwar möglich, kommt aber mit diversen Einschränkungen. Gründe die Gegen eine partitionslose BtrFS Festplatte sprechen: | Es empfiehlt sich eine Partition für BtrFS anzulegen. Eine partitionslose Installation bei der das Dateisystem direkt auf die Festplatte (z.B. {{ic|/dev/sda}} statt {{ic|/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 | * Auf UEFI Systemen ist eine EFI Partition notwendig | ||
* | * BIOS/GPT Setups benötigt GRUB eine BIOS BOOT Partition | ||
* Btrfs unterstützt erst seit Kernel 5.0 Swap-Dateien, frühere Versionen benötigen eine Swap-Partition | * Btrfs unterstützt erst seit Kernel 5.0 Swap-Dateien, frühere Versionen benötigen eine Swap-Partition | ||
| Zeile 35: | Zeile 35: | ||
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 auch das Verzeichnis {{ic|/var}} nicht unnötig sondern enthält z.B. den Ordner {{ic|/var/lib}} in welchem '''pacman''' Informationen über die installierten Pakete speichert. Lediglich Ordner wie {{ic|/var/cache}}, {{ic|/var/log}}, {{ic|/var/spool}} und {{ic|/var/tmp}} 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 vom root-User ({{ic|/root}}) wird in den meisten Fällen auch nicht benötigt, da dort im Idealfall keine wichtigen Daten liegen sollten (man vergleiche es mit der Besenkammer des Hausmeisters). Aus anderen Gründen verhält es sich ähnlich mit dem Verzeichnis für Services ({{ic|/srv}}) welches ebenfalls aus dem Snapshot ausgeschlossen werden kann (für Heimsysteme ist {{ic|/srv}} meistens ohnehin leer). | 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 auch das Verzeichnis {{ic|/var}} nicht unnötig sondern enthält z.B. den Ordner {{ic|/var/lib}} in welchem '''pacman''' Informationen über die installierten Pakete speichert. Lediglich Ordner wie {{ic|/var/cache}}, {{ic|/var/log}}, {{ic|/var/spool}} und {{ic|/var/tmp}} 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 vom root-User ({{ic|/root}}) wird in den meisten Fällen auch nicht benötigt, da dort im Idealfall keine wichtigen Daten liegen sollten (man vergleiche es mit der Besenkammer des Hausmeisters). Aus anderen Gründen verhält es sich ähnlich mit dem Verzeichnis für Services ({{ic|/srv}}) welches ebenfalls aus dem Snapshot ausgeschlossen werden kann (für Heimsysteme ist {{ic|/srv}} meistens ohnehin leer). | ||
# mount -o rw,noatime,compress= | # mount -o rw,noatime,compress=zstd:3 /dev/sda1 /mnt | ||
# btrfs subvol create /mnt/arch | # btrfs subvol create /mnt/arch | ||
# btrfs subvol create /mnt/root | # btrfs subvol create /mnt/arch/root | ||
# btrfs subvol create /mnt/srv | # btrfs subvol create /mnt/arch/srv | ||
# mkdir /mnt/arch/var | # mkdir /mnt/arch/var | ||
# mkdir /mnt/arch/snapshots | |||
# mkdir /mnt/arch/root/arch_pool | |||
# mkdir /mnt/arch/root/home_pool | |||
# btrfs subvol create /mnt/arch/var/cache | # btrfs subvol create /mnt/arch/var/cache | ||
| Zeile 51: | Zeile 51: | ||
# btrfs subvol create /mnt/arch/var/tmp | # btrfs subvol create /mnt/arch/var/tmp | ||
# | # btrfs subvol list /mnt | ||
# mount -o rw,noatime,compress= | |||
# mkdir /mnt | Es empfiehlt sich, nochmal zu prüfen ob alle benötigten Subvolumen erstellt wurden und die ID des arch subvolumens zu notieren (sollte 256 sein). Anschließend kann das Volumen ausgehängt werden. | ||
# mkdir /mnt | |||
# umount /mnt | |||
Nun sollten die Subvolumen für die Benutzerordner angelegt werden. Die Erstellung der Subvolumen muss für jeden neuen Benutzer erneut ausgeführt werden. Es empfielt sich daher für später einen einen Bash-Script zu erstellen. Die Namen der Benutzerordner kann man zB aus den XDG Konfigurationsdateien auslesen. '''useradd''' hat die flag '''---btrfs-subvolume-home''' um das home-Verzeichnis neuer User als Subvolumen anlegen zu lassen. Dies legt das subvolumen aber in /dev/sda1 an und die Benutzerdatenordner, welche als subvolumen gewünscht sind muss man dennoch händisch als subvolumen anlegen. | |||
# mount -o rw,noatime,compress=zstd:3 /dev/sdb1 /mnt | |||
# mkdir /mnt/snapshots | |||
# mkdir /mnt/snapshots/BENUTZERNAME | |||
# btrfs subvol create /mnt | # btrfs subvol create /mnt/BENUTZERNAME | ||
# btrfs subvol create /mnt | # btrfs subvol create /mnt/BENUTZERNAME/Dokumente | ||
# btrfs subvol create /mnt | # btrfs subvol create /mnt/BENUTZERNAME/Downloads | ||
# btrfs subvol create /mnt | # btrfs subvol create /mnt/BENUTZERNAME/Musik | ||
# btrfs subvol create /mnt | # btrfs subvol create /mnt/BENUTZERNAME/Bilder | ||
# btrfs subvol cr... usw. usf. | # btrfs subvol cr... usw. usf. | ||
# btrfs subvol list /mnt | |||
Nun alle ID für die Subvolumen aller angelegten Benutzer notieren, diese werden später zum einhängen der Subvolumen und zur Erstellung der fstab benötigt. anschließend kann das Volumen ausgehängt werden. | |||
# umount /mnt | |||
Die Snapshots Ordner werden später zur Ablage der Snapshots benutzt. Das Wurzeldateisystem 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 {{ic|/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{{ic|/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 {{ic|/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'' und entsprechenden untergeordneten Subvolumen angelegt werden. | Die Snapshots Ordner werden später zur Ablage der Snapshots benutzt. Das Wurzeldateisystem 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 {{ic|/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{{ic|/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 {{ic|/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'' und entsprechenden untergeordneten Subvolumen angelegt werden. | ||
=== Weitere Installation === | === Weitere Installation === | ||
Bis zum Schritt pacstrap folgt alles weiter der Arch Linux Installationsanleitung. beim pacstrap Schritt sollte das Paket '''btrfs-progs''' | Die BtrFS Partitionen sollten nun als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann. | ||
# mount -o rw,noatime,subvol=arch,subvolid=256,compress=zstd:3 /dev/sda1 /mnt | |||
# mkdir /mnt/home/BENUTZERNAME | |||
# mount -o rw,noatime,subvol=BENUTZERNAME,subvolid=...,compress=zstd:3 /dev/sdb1 /mnt/home/BENUTZERNAME | |||
Bis zum Schritt pacstrap folgt nun alles weiter der Arch Linux Installationsanleitung. beim pacstrap Schritt sollte zusätzlich das Paket '''btrfs-progs''' installiert werden, da dieses nicht in der ''base''-Gruppe enthalten ist. | |||
=== fstab bearbeiten === | === fstab bearbeiten === | ||
| Zeile 76: | Zeile 96: | ||
# <file system> <dir> <type> <options> <dump> <pass> | # <file system> <dir> <type> <options> <dump> <pass> | ||
# root file system /dev/sda1 | # root file system /dev/sda1 | ||
UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress= | UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress=zstd:3 | ||
UUID=... / | UUID=... / btrfs rw,ssd,discard,noatime,subvol=root,subvolid=...,compress=zstd:3 | ||
# user home directories /dev/sdb1 | # user home directories /dev/sdb1 | ||
UUID=... /home/BENUTZERNAME btrfs rw,ssd,discard,noatime,subvol=BENUTZERNAME,subvolid=...,compress= | UUID=... /home/BENUTZERNAME btrfs rw,ssd,discard,noatime,subvol=BENUTZERNAME,subvolid=...,compress=zstd:3 | ||
# btrfs-top-levels | # btrfs-top-levels | ||
UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress= | UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3 | ||
UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress= | UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3 | ||
Die UUID für /, | Die UUID für '''/''', sowie für '''/root/arch_pool''', entspricht der UUID von /dev/sda1. | ||
Die UUID für die | Die UUID für die '''home'''-Verzeichnisse, sowie für '''/root/home_pool''', entspricht der UUID von /dev/sdb1. | ||
Die | UUID ermittelt man mit '''lsblk -o NAME,UUID'''. | ||
Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit '''btrfs subvol list /'''. | |||
Datenkompression erhöht die Geschwindigkeit für Copy-on-Write zu lasten der CPU. Der Overhead (zusätzlich Leistung die von der CPU erbracht werden muss) ist allerdings vernachlässigbar gering. {{ic|lzo}} ist ein auf Geschwindigkeit optimierter Algorithmus. BtrFS kennt noch einen langsamen aber effizienteren Kompressionsalgorithmus ({{ic|zlib}}) und den effektiven und schnellen {{ic|zstd}}. Benutzt man {{ic|zstd}} können ältere GRUB-Versionen das System nicht booten. Natürlich könnte man {{ic|/boot}} auf eine eigene Partition auslagern und bei jedem Snapshot einzeln sichern, dies ist den Aufwand nicht Wert, wenn man das Risiko bedenkt es einmal zu vergessen. Die aktuelle Version von Grub im repository unterstützt {{ic|zstd}}. Die Option {{ic|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 {{ic|ssd}} und discard und daher eher redundant, mount mag es aber, wenn redundante Angaben explizit angegeben werden. Ob man {{ic|discard}} verwenden will ist einem selbst überlassen, die Meinungen gehen hierzu auseinander. Näheres im Artikel über SSD Festplatten. | |||
Datenkompression erhöht die Geschwindigkeit für Copy-on-Write zu lasten der CPU. Der Overhead (zusätzlich Leistung die von der CPU erbracht werden muss) ist allerdings vernachlässigbar gering. {{ic|lzo}} ist ein auf Geschwindigkeit optimierter Algorithmus. BtrFS kennt noch einen langsamen aber effizienteren Kompressionsalgorithmus ({{ic|zlib}}) und den effektiven und schnellen {{ic|zstd}}. Benutzt man {{ic|zstd}} können ältere GRUB-Versionen das System nicht booten. Natürlich könnte man {{ic|/boot}} auf eine eigene Partition auslagern und bei jedem Snapshot einzeln sichern, dies ist den Aufwand nicht Wert, wenn man das Risiko bedenkt es einmal zu vergessen. Die Option {{ic|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 {{ic|ssd}} und discard und daher eher redundant, mount mag es aber, wenn redundante Angaben explizit angegeben werden. Ob man {{ic|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 === | === Installation zu Ende führen und Bootloader installieren === | ||
| Zeile 109: | Zeile 126: | ||
Der Snapshots enthält da gesamte Wurzeldateisystem mit Ausnahme der Subvolumen {{ic|/root}}, {{ic|/srv}}, {{ic|/var/cache}}, {{ic|/var/log}}, {{ic|/var/spool}} und {{ic|/var/tmp}}. | Der Snapshots enthält da gesamte Wurzeldateisystem mit Ausnahme der Subvolumen {{ic|/root}}, {{ic|/srv}}, {{ic|/var/cache}}, {{ic|/var/log}}, {{ic|/var/spool}} und {{ic|/var/tmp}}. | ||
ein gut zum sortieren geeigneter Zeitstempel (Jahr_Monat_Tag_Sekunden-seit-Mitternacht) lässt sich wie folgt erstellen ( | ein gut zum sortieren geeigneter Zeitstempel (Jahr_Monat_Tag_Sekunden-seit-Mitternacht) lässt sich wie folgt erstellen (als Bashscript Speichern unter {{ic|/usr/local/bin/timestamp}}: | ||
#!/bin/bash | |||
# Concatenate current date with seconds from midnight | |||
echo $(date +%y_%m_%d)_$(( $(date +%s) - $(date -d 'today 0' +%s) )) | |||
Anschließend noch die Permissions setzen: | |||
# chmod 755 /usr/local/bin/timestamp | |||
Snapshots der Benutzerdaten können Analog hierzu erstellt werden. Zu beachten gilt lediglich, dass Snapshots an den Subvolumengrenzen aufhören und von diesen dann expliziet ein eigener Snapshot erstellt werden muss. Beim oben erläutertem Schema für Subvolumen würde der Snapshot des Benutzer-Heimverzeichnisses lediglich die dort direkt abgelegten Daten und die diversen Einstellungsdateien und lokalen Dateien (z.B. '''.local''') enthalten. Der als eigenes Subvolumen angelegte Ordner für Dokumente muss als eigener Snapshot gesichert werden. | Snapshots der Benutzerdaten können Analog hierzu erstellt werden. Zu beachten gilt lediglich, dass Snapshots an den Subvolumengrenzen aufhören und von diesen dann expliziet ein eigener Snapshot erstellt werden muss. Beim oben erläutertem Schema für Subvolumen würde der Snapshot des Benutzer-Heimverzeichnisses lediglich die dort direkt abgelegten Daten und die diversen Einstellungsdateien und lokalen Dateien (z.B. '''.local''') enthalten. Der als eigenes Subvolumen angelegte Ordner für Dokumente muss als eigener Snapshot gesichert werden. | ||
| Zeile 122: | Zeile 146: | ||
=== Vorherige Systemzustände mit Snapshots wiederherstellen === | === Vorherige Systemzustände mit Snapshots wiederherstellen === | ||
Um einzelne Dateien wieder herzustellen muss nicht gleich das ganze Subvolumen zurück gesetzt werden. Es genügt, den Snapshot vorübergehend einzuhängen und die wiederherzustellende Datei einfach zu kopieren. Soll hingegen das gesamte Subvolumen zurück gesetzt werden, reicht es dieses durch einen schreibbaren Snapshot zu ersetzen. Der Sicherheitshalber empfiehlt es sich aber as aktuelle Subvolume vorher umzubenennen | Um einzelne Dateien wieder herzustellen muss nicht gleich das ganze Subvolumen zurück gesetzt werden. Es genügt, den Snapshot vorübergehend einzuhängen und die wiederherzustellende Datei einfach zu kopieren. Soll hingegen das gesamte Subvolumen zurück gesetzt werden, reicht es dieses durch einen schreibbaren Snapshot zu ersetzen. Der Sicherheitshalber empfiehlt es sich aber as aktuelle Subvolume vorher umzubenennen. Damit wird sichergestellt, dass der zustand vor dem zurücksetzen notfalls wieder hergestellt werden kann (zB wenn man einen falschen Snapshot geladen hat). Wenn alles funktioniert kann '''arch.old''' entfernt werden. | ||
# mount /root/arch_pool | # mount /root/arch_pool | ||
# mv /root/arch_pool/arch /root/arch_pool/arch.old | # mv /root/arch_pool/arch /root/arch_pool/arch.old | ||
# btrfs subvolume snapshot /root/arch_pool/snapshots/arch_ZEITSTEMPEL /root/arch_pool/arch | # btrfs subvolume snapshot /root/arch_pool/snapshots/arch_ZEITSTEMPEL /root/arch_pool/arch | ||
Ersetzt man das ganze Subvolumen, so hat das wiederhergestellte System hat eine andere subvolid als das ersetze. Diese muss nun in der fstab eingetragen werden. Untergeordnete Subvolumen müssen ebenfalls neu angelegt werden, sofern sie nicht als eigenständige subvolumen im top-level des BtrFS Volumen angelegt und separat eingehängt worden sind. Es empfielt sich daher folgenden Anweisungsblock als Bash-Script anzulegen ({{ic|/usr/local/bin/create_ballast}}). | |||
#!/bin/bash | |||
cd /root/arch_pool/arch | |||
rmdir srv var/cache var/log var/spool var/tmp | |||
btrfs create subvol srv | |||
btrfs create subvol var/cache | |||
btrfs create subvol var/log | |||
btrfs create subvol var/spool | |||
btrfs create subvol var/tmp | |||
Anschließend noch die Permissions auf root beschränkt setzen. | |||
# chmod 700 /user/local/bin/timestamp | |||
=== Subvolumen/Snapshots löschen === | === Subvolumen/Snapshots löschen === | ||
Subvolumen (Snapshots sind Subvolumen) mögen sich zwar in fast allen Aspekten wie Ordner verhalten, bleiben aber | Subvolumen (Snapshots sind Subvolumen) mögen sich zwar in fast allen Aspekten wie Ordner verhalten, bleiben aber Subvolumen. Bis zum Linux Kernel 4.18 war es, auch als root, nicht möglich subvolumen wie Ordner zu löschen. Stattdessen muss, wie bei der Erstellung von subvolumen, das entsprechende '''btrfs-progs''' Progamm genutzt werden: | ||
# rm -rf SNAPSHOT | # rm -rf SNAPSHOT | ||
rm: cannot remove 'SNAPSHOT' : Operation not permitted | rm: cannot remove 'SNAPSHOT' : Operation not permitted | ||
# btrfs subvolume delete SNAPSHOT | # btrfs subvolume delete SNAPSHOT | ||
Seit Linux 4.18 ist es möglich, Btrfs-Subvolumes mit '''rm -r''' bzw. '''rmdir''' zu löschen. Während dies grundsätzlich nur dem Superuser erlaubt ist, kann es dem jeweiligen Besitzer des Subvolumes durch Setzen der Mount-Option "'''user_subvol_rm_allowed'''" ebenfalls gestattet werden [https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature Btrfs-Wiki], [https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#MOUNT_OPTIONS btrfs(5)]. | |||
== Echte Backups mit Btrfs erstellen == | == Echte Backups mit Btrfs erstellen == | ||
Aktuelle Version vom 17. Februar 2022, 16:41 Uhr
Hinweis: BtrFS befindet sich noch in der Entwicklung. Einige fortgeschrittenere Funktionen weisen daher noch Fehler auf. Genereller Konsens ist aber, dass BtrFS weitestgehend stabil ist. Detailliertere Auskunft gibt das (englischsprachige) BtrFS Wiki Status, Is BtrFS stable? und Getting started.
Diese Seite stellt einen groben Überblick zum Dateisystem BtrFS dar und erläutert was beachtet werden muss um Arch auf BtrFS zu installieren.
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 Original 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, was einer Maximalgröße gleich käme. Allerdings wird noch darüber gestritten wie stabil diese Funktion ist). Im Verzeichnisbaum erscheinen und verhalten sich Subvolumen eines eingehängten BtrFS-Volumens als Ordner und werden automatisch eingehängt. In Ubuntu-Derivaten und OpenSUSE hat es sich eingebürgert Top-Level-Subvolumen mit einem vorangestellten @ zu benennen. Dies ist eine reine Konvention unter den Nutzern diese Linux-Derivate und formell nicht nötig. Subvolumen bedürfen keiner speziellen Nomenklatur. Es ist sogar hinderlich, da jedes Subvolumen welches anders heißt als wie vom System erwartet explizit eingehängt werden muss.
BtrFS erlaubt es spezielle Subvolumen, sogenannte 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 Betrieb 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/GPT Setups benötigt GRUB eine BIOS BOOT Partition
- Btrfs unterstützt erst seit Kernel 5.0 Swap-Dateien, frühere Versionen benötigen 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 vielleicht 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 und 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 worden sind. 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 auch 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/tmp 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 vom root-User (/root) wird in den meisten Fällen auch nicht benötigt, da dort im Idealfall keine wichtigen Daten liegen sollten (man vergleiche es mit der Besenkammer des Hausmeisters). Aus anderen Gründen verhält es sich ähnlich mit dem Verzeichnis für Services (/srv) welches ebenfalls aus dem Snapshot ausgeschlossen werden kann (für Heimsysteme ist /srv meistens ohnehin leer).
# mount -o rw,noatime,compress=zstd:3 /dev/sda1 /mnt
# btrfs subvol create /mnt/arch # btrfs subvol create /mnt/arch/root # btrfs subvol create /mnt/arch/srv
# mkdir /mnt/arch/var # mkdir /mnt/arch/snapshots # mkdir /mnt/arch/root/arch_pool # mkdir /mnt/arch/root/home_pool
# 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/tmp
# btrfs subvol list /mnt
Es empfiehlt sich, nochmal zu prüfen ob alle benötigten Subvolumen erstellt wurden und die ID des arch subvolumens zu notieren (sollte 256 sein). Anschließend kann das Volumen ausgehängt werden.
# umount /mnt
Nun sollten die Subvolumen für die Benutzerordner angelegt werden. Die Erstellung der Subvolumen muss für jeden neuen Benutzer erneut ausgeführt werden. Es empfielt sich daher für später einen einen Bash-Script zu erstellen. Die Namen der Benutzerordner kann man zB aus den XDG Konfigurationsdateien auslesen. useradd hat die flag ---btrfs-subvolume-home um das home-Verzeichnis neuer User als Subvolumen anlegen zu lassen. Dies legt das subvolumen aber in /dev/sda1 an und die Benutzerdatenordner, welche als subvolumen gewünscht sind muss man dennoch händisch als subvolumen anlegen.
# mount -o rw,noatime,compress=zstd:3 /dev/sdb1 /mnt
# mkdir /mnt/snapshots # mkdir /mnt/snapshots/BENUTZERNAME
# btrfs subvol create /mnt/BENUTZERNAME # btrfs subvol create /mnt/BENUTZERNAME/Dokumente # btrfs subvol create /mnt/BENUTZERNAME/Downloads # btrfs subvol create /mnt/BENUTZERNAME/Musik # btrfs subvol create /mnt/BENUTZERNAME/Bilder # btrfs subvol cr... usw. usf.
# btrfs subvol list /mnt
Nun alle ID für die Subvolumen aller angelegten Benutzer notieren, diese werden später zum einhängen der Subvolumen und zur Erstellung der fstab benötigt. anschließend kann das Volumen ausgehängt werden.
# umount /mnt
Die Snapshots Ordner werden später zur Ablage der Snapshots benutzt. Das Wurzeldateisystem 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 und entsprechenden untergeordneten Subvolumen angelegt werden.
Weitere Installation
Die BtrFS Partitionen sollten nun als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann.
# mount -o rw,noatime,subvol=arch,subvolid=256,compress=zstd:3 /dev/sda1 /mnt # mkdir /mnt/home/BENUTZERNAME # mount -o rw,noatime,subvol=BENUTZERNAME,subvolid=...,compress=zstd:3 /dev/sdb1 /mnt/home/BENUTZERNAME
Bis zum Schritt pacstrap folgt nun alles weiter der Arch Linux Installationsanleitung. beim pacstrap Schritt sollte zusätzlich das Paket btrfs-progs installiert werden, da dieses nicht in der 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=zstd:3 UUID=... / btrfs rw,ssd,discard,noatime,subvol=root,subvolid=...,compress=zstd:3
# user home directories /dev/sdb1 UUID=... /home/BENUTZERNAME btrfs rw,ssd,discard,noatime,subvol=BENUTZERNAME,subvolid=...,compress=zstd:3
# btrfs-top-levels UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3 UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3
Die UUID für /, sowie für /root/arch_pool, entspricht der UUID von /dev/sda1.
Die UUID für die home-Verzeichnisse, sowie für /root/home_pool, entspricht der UUID von /dev/sdb1.
UUID ermittelt man mit lsblk -o NAME,UUID.
Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit btrfs subvol list /.
Datenkompression erhöht die Geschwindigkeit für Copy-on-Write zu lasten der CPU. Der Overhead (zusätzlich Leistung die von der CPU erbracht werden muss) ist allerdings vernachlässigbar gering. lzo ist ein auf Geschwindigkeit optimierter Algorithmus. BtrFS kennt noch einen langsamen aber effizienteren Kompressionsalgorithmus (zlib) und den effektiven und schnellen zstd. Benutzt man zstd können ältere GRUB-Versionen das System nicht booten. Natürlich könnte man /boot auf eine eigene Partition auslagern und bei jedem Snapshot einzeln sichern, dies ist den Aufwand nicht Wert, wenn man das Risiko bedenkt es einmal zu vergessen. Die aktuelle Version von Grub im repository unterstützt zstd. Die Option 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 regulären Installationsanleitung. Als Bootloader empfiehlt sich GRUB. Alle anderen funktionieren mit BtrFS nicht oder nur mit schweren Einschränkungen (keine Kompression, keine RAIDS, etc.).
Snapshots
Snapshots erstellen
Einen Snapshot des Systems (ohne Benutzerdaten) 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/tmp.
ein gut zum sortieren geeigneter Zeitstempel (Jahr_Monat_Tag_Sekunden-seit-Mitternacht) lässt sich wie folgt erstellen (als Bashscript Speichern unter /usr/local/bin/timestamp:
#!/bin/bash # Concatenate current date with seconds from midnight echo $(date +%y_%m_%d)_$(( $(date +%s) - $(date -d 'today 0' +%s) ))
Anschließend noch die Permissions setzen:
# chmod 755 /usr/local/bin/timestamp
Snapshots der Benutzerdaten können Analog hierzu erstellt werden. Zu beachten gilt lediglich, dass Snapshots an den Subvolumengrenzen aufhören und von diesen dann expliziet ein eigener Snapshot erstellt werden muss. Beim oben erläutertem Schema für Subvolumen würde der Snapshot des Benutzer-Heimverzeichnisses lediglich die dort direkt abgelegten Daten und die diversen Einstellungsdateien und lokalen Dateien (z.B. .local) enthalten. Der als eigenes Subvolumen angelegte Ordner für Dokumente muss als eigener Snapshot gesichert werden.
# mount /root/home_pool # btrfs subvol snapshot /root/home_pool/BENUTZERNAME /root/home_pool/snapshots/BENUTZERNAME_ZEITSTEMPEL # btrfs subvol snapshot /root/home_pool/BENUTZERNAME/Dokumente /root/home_pool/snapshots/BENUTZERNAME/Dokumente_ZEITSTEMPEL # btrfs subvol snapshot /root/home_pool/BENUTZERNAME/... /root/home_pool/snapshots/BENUTZERNAME/..._ZEITSTEMPEL # umount /root/home_pool
Vorherige Systemzustände mit Snapshots wiederherstellen
Um einzelne Dateien wieder herzustellen muss nicht gleich das ganze Subvolumen zurück gesetzt werden. Es genügt, den Snapshot vorübergehend einzuhängen und die wiederherzustellende Datei einfach zu kopieren. Soll hingegen das gesamte Subvolumen zurück gesetzt werden, reicht es dieses durch einen schreibbaren Snapshot zu ersetzen. Der Sicherheitshalber empfiehlt es sich aber as aktuelle Subvolume vorher umzubenennen. Damit wird sichergestellt, dass der zustand vor dem zurücksetzen notfalls wieder hergestellt werden kann (zB wenn man einen falschen Snapshot geladen hat). Wenn alles funktioniert kann arch.old entfernt werden.
# mount /root/arch_pool # mv /root/arch_pool/arch /root/arch_pool/arch.old # btrfs subvolume snapshot /root/arch_pool/snapshots/arch_ZEITSTEMPEL /root/arch_pool/arch
Ersetzt man das ganze Subvolumen, so hat das wiederhergestellte System hat eine andere subvolid als das ersetze. Diese muss nun in der fstab eingetragen werden. Untergeordnete Subvolumen müssen ebenfalls neu angelegt werden, sofern sie nicht als eigenständige subvolumen im top-level des BtrFS Volumen angelegt und separat eingehängt worden sind. Es empfielt sich daher folgenden Anweisungsblock als Bash-Script anzulegen (/usr/local/bin/create_ballast).
#!/bin/bash cd /root/arch_pool/arch rmdir srv var/cache var/log var/spool var/tmp btrfs create subvol srv btrfs create subvol var/cache btrfs create subvol var/log btrfs create subvol var/spool btrfs create subvol var/tmp
Anschließend noch die Permissions auf root beschränkt setzen.
# chmod 700 /user/local/bin/timestamp
Subvolumen/Snapshots löschen
Subvolumen (Snapshots sind Subvolumen) mögen sich zwar in fast allen Aspekten wie Ordner verhalten, bleiben aber Subvolumen. Bis zum Linux Kernel 4.18 war es, auch als root, nicht möglich subvolumen wie Ordner zu löschen. Stattdessen muss, wie bei der Erstellung von subvolumen, das entsprechende btrfs-progs Progamm genutzt werden:
# rm -rf SNAPSHOT rm: cannot remove 'SNAPSHOT' : Operation not permitted # btrfs subvolume delete SNAPSHOT
Seit Linux 4.18 ist es möglich, Btrfs-Subvolumes mit rm -r bzw. rmdir zu löschen. Während dies grundsätzlich nur dem Superuser erlaubt ist, kann es dem jeweiligen Besitzer des Subvolumes durch Setzen der Mount-Option "user_subvol_rm_allowed" ebenfalls gestattet werden Btrfs-Wiki, btrfs(5).
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.
Bestehende EXT3/4 Dateisysteme in BtrFS Dateisysteme umwandeln
Bestehende EXT3/4 Dateisysteme können in BtrFS Dateisysteme umgewandelt werden. Ohne Backup und Zeit das System evtl. komplett neu aufsetzen zu müssen ist hiervon aber dringend abzuraten Die BtrFS-Mailingliste quellt über mit Hilfsgesuchen nach gescheiterten EXT zu BtrFS unwandlungen. Zudem entfaltet BtrFS erst dann seine volle Stärke, wenn man eine entsprechend leicht zu Wartende Struktur aus Subvolumen angelegt hat.
Wer es dennoch versuchen will sollte mit einem Backup anfangen. Man sollte sich nocheinmal versichern, dass für später auch wirklich alle BtrFS packete installiert sind und dann von einem Arch Installationsmedium booten und folgendes ausführen:
# btrfs-convert /dev/PARTITION
Ändert nun den Partitionstyp zu BtrFS. Anschließend muss die fstab angepasst werden. btrfs-convert legt ein eigenes Backup an, dies kann anschließend gelöscht werden:
# btrfs subvolume delete /..._saved