Arch auf BtrFS: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
KKeine Bearbeitungszusammenfassung
(Hint für die Ermittlung und Verwendung der UUIDs.)
(22 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
==Arch-Linux auf ein BtrFS-System==
{{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 [https://btrfs.wiki.kernel.org/index.php/Status Status], [https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F Is BtrFS stable?] und [https://btrfs.wiki.kernel.org/index.php/Getting_started Getting started].}}
<br>
{{righttoc}}
Hier wird beschrieben wie ich ein BtrFS-System erstelle, wo man mit einem Snapshot nur / speichert. Die Verzeichnisse /home, /var/lib/cache/pacman/pkg und wie bei mir /Daten bleiben aussen vor und sind extra per snapshot zu sichern. Dies ist interessant für System-Updates, schnell ein System-Update mit vorherigen snapshot der Root-Partition erstellen ohne Ballast
Diese Seite stellt einen groben Überblick zum Dateisystem BtrFS dar und erläutert was beachtet werden muss um Arch auf BtrFS zu installieren.
wie pkg oder home, Daten etc. also ein kleines schnelles snapshot.
<br>
Inspiriert wurde ich von unicks.eu, der inzwischen eine kpl. neue Serie gedreht hat die da lautet  "Arch my way"<br>


Der Artikel ist so beschrieben wie mein System läuft und möglichts viel integriert. So kann man weglassen was man nicht braucht oder weitere scripte einbinden. Es sind also viele Änderungen möglich.
== Was ist BtrFS ==
Wenn jemand kein EFI nutzt so braucht man auch keine vFat Formatierung und EFI-Partition. Man kann diese Partition aber als ext4 formatieren da grub evtl. Probleme mit BtrFS Boot-Partition hat.
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.
<br>
Datensicherung- und Update-Script sind unter Scripte zu finden, sowie auch ein kpl. Terminal-Menü. Links unten am Ende dieses Artikels.
<br>
''Ich gehe davon aus, dass ein USB-Stick mit neustem Arch-Images startbar vorliegt. Weiter, das es eine kpl. Neuinstallation ist ohne Dualboot. Sonst entsprechend die Plattenbezeichnung ändern. Diese Beschreibung erklärt die Installation mit 2 SSD die im Raid0 / 1 ''(raid 5/6 läuft zur Zeit nicht stabil)'' laufen. Es ist aber auch möglich nur eine Platte zu nutzen''<br>
<br>
Mit hilfe des Sticks starten wir den Rechner, ist der Prompt zu sehen, stellen wir das System auf der deutschen Tastatur um, mit ''loadkeys de''. Die Arbeit wird hier durch doch erleichtert.<br>
<br>
Jetzt prüfe ich erstmal was an Platten vorhanden ist. Mit ''fdisk -l'' (l = kleines L) <br>
''Anmerkung:sudo ist nicht von nöten, da das System per Stick mit root gestartet wird''<br>
Die Ausgabe fdisk -l ist bei mir (man sieht wie es mal aussehen sollte, da schon eingerichtet):
<br>
[Amber@DX1701 ~]$ sudo fdisk -l
[sudo] Passwort für Amber:
Festplatte /dev/sda: 232,9 GiB, 250059350016 Bytes, 488397168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 8445CB1C-5B69-453B-A039-BB98A9C39955
Gerät        Anfang      Ende  Sektoren Größe Typ
/dev/sda1      2048  1026047  1024000  500M EFI-System
/dev/sda2    1026048 470788095 469762048  224G Linux-Dateisystem
/dev/sda3  470788096 488397134  17609039  8,4G Linux Swap
 
Festplatte /dev/sdb: 223,6 GiB, 240057409536 Bytes, 468862128 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 8A3B18E3-CDAB-4880-8B42-4B13359A488C
Gerät      Anfang      Ende  Sektoren  Größe Typ
/dev/sdb1    2048 468862094 468860047 223,6G Linux-Dateisystem
<br>
''Anmerkung:Das Amber@DX1701 ist mein Name und Rechnername, bei euch steht also etwas anderes wie [root@xxxxx ~]#''<br>
<br>
Man sieht, die erste Platte sda hat die Partitionen


/dev/sda1      2048  1026047  1024000  500M EFI-System
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.
/dev/sda2    1026048 470788095 469762048  224G Linux-Dateisystem
/dev/sda3  470788096 488397134  17609039  8,4G Linux Swap


die zweite Platte folgende
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.
/dev/sdb1    2048 468862094 468860047 223,6G Linux-Dateisystem


So habe ich das ganze aufgebaut:<br>
BtrFS unterstützt RAIDS und kann diese im Betrieb vergrößern, verkleinern und zwischen verschiedenen RAID Typen konvertieren.
<br>
'''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 [https://btrfs.wiki.kernel.org/index.php/RAID56 the Btrfs page on RAID5 and RAID6] for status updates.
Ich haben hier also sda und sdb als Platten und fangen mit sda an und rufe ein Partitionierungsprogramm auf mit Hilfe von fdisk /dev/sda um die erste Platte einzurichten.<br>
Es erscheint im Terminal:<br>


[Amber@DX1701 ~]$ sudo fdisk /dev/sda
== Installation von Arch Linux auf Btrfs ==
[sudo] Passwort für Amber:
Die die Installation verläuft bis auf wenige Ausnahmen wie auf anderen Dateisystemen.


Willkommen bei fdisk (util-linux 2.30.1).                                                                                                                                                                            
=== Partitionierung der Festplatte ===
Änderungen werden vorerst nur im Speicher vorgenommen, bis Sie sich
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:
entscheiden, sie zu schreiben.
* Auf UEFI Systemen ist eine EFI Partition notwendig
Seien Sie vorsichtig, bevor Sie den Schreibbefehl anwenden.
* bios/GTP 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
Befehl (m für Hilfe): m


Mit m (anschließend mit Enter/Return bestätigen) erhält man ein Hilfemenü  um die Funktionen von fdisk zu sehen.<br>
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.
Es erscheint:
Hilfe:
  Allgemein
  d  Eine Partition löschen
  F  Größe des unpartitionierten Bereichs anzeigen
  l  Die bekannten Dateisystemtypen anzeigen
  n  Eine neue Partition anlegen
  p  Die Partitionstabelle ausgeben
  t  Einen Partitionstyp ändern
  v  Die Partitionstabelle überprüfen
  i  Informationen über eine Partition ausgeben
  Sonstiges
  m  Dieses Menü anzeigen
  x  Zusätzliche Funktionen (nur für Experten)
  Skript
  I  Plattenlayout aus einer sfdisk-Skriptdatei laden
  O  Plattenlayout in eine sfdisk-Skriptdatei schreiben
  Speichern und Beenden
  w  Die Tabelle auf die Festplatte schreiben und das Programm beenden
  q  Beenden ohne Speichern der Änderungen
  Eine neue Bezeichnung erstellen
  g  Eine neue leere GPT-Partitionstabelle erstellen
  G  Eine neue leere SGI (IRIX)-Partitionstabelle erstellen
  o  Eine neue leere DOS-Partitionstabelle erstellen
  s  Eine neue leere Sun-Partitionstabelle erstellen
  Befehl (m für Hilfe):
<br>
Ich brauche also ausgehend von leeren Platten, g, n, t, p und w.<br>
''Anmerkung:Die arbeiten die man vornimmmt werden erst umgesetzt wenn man mit w speichern und Ende bestätige!!''<br>
Ich kann alles ausser Letzter Sektor mit Enter bestätigen, letzter Sektor wird mit Eingabe der Grüße der Partition (+Größe{K,M,G,T,P}). Beispiel +500M wäre 500MB groß.<br>
Ich fange mit g an und erhalte:


Befehl (m für Hilfe): g
Nehmen wir ein System mit zwei SSD-Festplatten mit je einer, die gesamte Platte einnehmende BtrFS Partition, an. Auf {{ic|/dev/sda}} soll Arch Linux und vielleicht noch etwas langweiliges wie Debian installiert werden, auf {{ic|/dev/sdb}} sollen die Daten der Benutzer liegen.
Eine neue GPT-Festplattenbezeichnung wurde erstellt (GUID: D85F0243-252D-412F-AAAE-89FCF5DA460C).
Befehl (m für Hilfe):


Nun habe ich eine Partitionstabelle und mache weiter mit n (neue Partition):
Sobald die Partition(en) angelegt ist/sind. Können die für BtrFS vorgesehenen Partitionen mit '''mkfs.btrfs''' formatiert werden.
Befehl (m für Hilfe): n
Partitionsnummer (1-128, Vorgabe 1):
Erster Sektor (34-976773134, Vorgabe 34):
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (34-976773134, Vorgabe 976773134): +500M
'''Eine neue Partition 1 des Typs „Linux filesystem“ und der Größe 500 MiB wurde erstellt.'''
Befehl (m für Hilfe):


Es wurde eine Partition mit 500MB erstellt, diese wird später in /boot eingehängt und in vFat formatiert (efi).<br>
# mkfs.btrfs -L "btrfs_pool" /dev/sda1
Weiter geht es mit n für die Root-Partition ''(eine /home wird es nicht geben da ich mit subvolume arbeite)''.
# mkfs.btrfs -L "btrfs_pool" /dev/sdb1


Befehl (m für Hilfe): n
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.
Partitionsnummer (2-128, Vorgabe 2):
Erster Sektor (1024034-976773134, Vorgabe 1024034):
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (1024034-976773134, Vorgabe 976773134): +224G
'''Eine neue Partition 2 des Typs „Linux filesystem“ und der Größe 224 GiB wurde erstellt.'''
Befehl (m für Hilfe):
<br>
Nun die letzte Partition für swap
Befehl (m für Hilfe): n
Partitionsnummer (3-128, Vorgabe 3):
Erster Sektor (470786082-976773134, Vorgabe 470786082):
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (470786082-976773134, Vorgabe 976773134):
'''Eine neue Partition 3 des Typs „Linux filesystem“ und der Größe 8,3 GiB wurde erstellt.'''
Befehl (m für Hilfe):


Jetzt wird der Typ für die erste und letzte Partition festgelegt da diese EFI-Partition und swap sind. Mit l kann man sich eine Liste anzeigen lassen.<br>
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).
Ich brauche 1 und 19 also gebe ich t ein, wähle meine Partition, hier 1 tippe dann nochmals 1 ein und die Ausgabe ist:


  Befehl (m für Hilfe): '''t'''
  # mount -o rw,noatime,compress=lzo /dev/sda1 /mnt
Partitionsnummer (1-3, Vorgabe 3): '''1'''
Partitionstyp (geben Sie L ein, um alle Typen aufzulisten): '''1'''
Partitionstyp von „Linux filesystem“ nach '''„EFI System“''' geändert.
Befehl (m für Hilfe):
Das ganze nochmals für die dritte Partition aber mit 19 für swap. Ausgabe:
Befehl (m für Hilfe): '''t'''
Partitionsnummer (1-3, Vorgabe 3): '''3'''
Partitionstyp (geben Sie L ein, um alle Typen aufzulisten): '''19'''
Partitionstyp von „Linux filesystem“ nach '''„Linux swap“''' geändert.


  Befehl (m für Hilfe):
  # btrfs subvol create /mnt/arch
Mit "p" aufgelistet sieht es so aus:
  # btrfs subvol create /mnt/root
Gerät        Anfang      Ende  Sektoren Größe Typ
  # btrfs subvol create /mnt/srv
/dev/sda1      2048  1026047  1024000  500M EFI-System          #EFI-Partition wird nach /boot gemountet
/dev/sda2    1026048 959424511 958398464  224G Linux-Dateisystem  #Root-Partition
/dev/sda3  959424512 976773134  17348623  8,3G Linux Swap          #Swap-Partition, wer viel Speicher hat kann diese weglassen oder verkleinern.
Befehl (m für Hilfe):
Nun schließe ich das ganze mit w ab und mit Enter bestätigen. Ergebniss:
Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert.
ioctl() wird aufgerufen, um die Partitionstabelle neu einzulesen.
Festplatten werden synchronisiert.
[Amber@DX1701 ~]$
und damit bin ich wieder am Prompt.<br>
<br>
Die sdb Platte muß noch eingerichtet werden. Das ist bei BtrFS nicht unbedingt notwendig, erstellt das Raid trotzdem, trotzdem mache ich es einfach wie folgt.<br>
fdisk /dev/sdb
dann einmal g
nun n
dreimal mit Enter bestätigen (ich will ja nur eine Partition).<br>
mit w abschließen.
<br>
<br>
Es geht weiter mit der Formatierung, ich nutze dabei Labels (Namen für die Partition). Der Befehl hierzu ist mkfs.btrfs -L "Name" /dev/sdXx und für Raid gibt es noch zusätzliche<br>
Parameter wie -m (Metadaten) -d (daten) raidX (welches raid). Beispiel mkfs.btrfs -L "Name" -m raid1 -d raid0 -L "BTRFS_RAID" /dev/sda1 /dev/sdb1<br>
<br>
Zuerst formatiere ich die EFI-Partition in vfat,setze Label mit EFI mit:
<br>
sudo mkfs.vfat -F 32 -n "EFI" /dev/sda1
<br>
Jetzt die Root-Partition, hier wird das raid gesetzt also sda2 mit sdb1. Hier habe ich für die Metadaten ein Raid1 (Mirroring – Spiegelung) und für die Daten also / Raid0 (Striping – Beschleunigung ohne Redundanz). weitere Infos [https://de.wikipedia.org/wiki/RAID hier]<br>
mkfs.btrfs -L "ARCH" -m raid1 -d raid0 /dev/sda2 /dev/sdb1
die swap erstelle ich mit
mkswap -L "SWAP" /dev/sda3
<br>
''Die Installation''<br>
<br>
Als erstes muß man die Subvolumen erzeugen und dafur bindet man die Root-Partition sda2 ein, sdb1 wird dann automatisch mit eingebunden.
<br>
mount /dev/sda2 /mnt/
<br>
Die Subvolume erzeugen, ich brauche /=@ home=@home Daten=@daten pkg=@pkg .snapshots=@snapshots
<br>
btrfs subvolume create /mnt/@
  btrfs subvolume create /mnt/@home
  btrfs subvolume create /mnt/@daten
btrfs subvolume create /mnt/@pkg
btrfs subvolume create /mnt/@snapshots
<br>
Diese subvolume sind alle gleichberechtigt wie man mit btrfs subvolume list -p /mnt sehen kann
<br>
[Amber@DX1701 /]$ sudo btrfs subvolume list -p /mnt
ID 257 gen 8 parent 5 ''top level 5'' path @
ID 258 gen 9 parent 5 ''top level 5'' path @home
ID 259 gen 10 parent 5 ''top level 5'' path @pkg
ID 260 gen 11 parent 5 ''top level 5'' path @snapshots
ID 261 gen 12 parent 5 ''top level 5'' path @daten
[Amber@DX1701 /]$
<br>
alle liegen im top level 5 so wird mit ein snapshot von / also @ auch nur dieses gesichert, @home, @pkg, @snapshots, @daten bleiben aussen vor.
<br>
Da das System in / also @ installiert werden soll muß jetzt sda2 ausgehängt werden mit
<br>
umount /mnt
<br>
und @ entsprechend nach /mnt gemountet und zwar so wie es in der fstab stehen soll,wer keine SSD hat eben kein ssd usw.
<br>
mount -o rw,noatime,compress=lzo,ssd,space_cache,subvol=@  /dev/sdc2 /mnt
<br>
es müssen nun die Verzeichnisse angelegt werden
<br>
mkdir /mnt/home/
mkdir /mnt/boot/
mkdir /mnt/.snapshots/
mkdir -p /mnt/home/Daten/
mkdir -p /mnt/var/cache/pacman/pkg/
<br>
''das -p steht für übergeordnete Verzeichnisse erzeugen was mit dem Verzeichniss pkg ja der Fall ist.''<br>
Jetzt kann der Rest eingebunden werden mit
mount -o rw,noatime,compress=lzo,ssd,space_cache,subvol=@home /dev/sdc2 /mnt/home/
mount -o rw,noatime,compress=lzo,ssd,space_cache,subvol=@pkg /dev/sdc2 /mnt/var/cache/pacman/pkg/
mount -o rw,noatime,compress=lzo,ssd,space_cache,subvol=@daten /dev/sdc2 /mnt/home/Daten/
mount -o rw,noatime,compress=lzo,ssd,space_cache,subvol=@snapshots /dev/sdc2 /mnt/.snapshots/
mount -o rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro /dev/sda1 /boot
swapon /dev/sda3
da alles vorbereitet ist Laufwerke eingebunden, diese mount-Parameter werden in der fstab durch genfstab übernommen. Daher kann die Installation starten mit
pacstrap /mnt base base-devel wpa_supplicant btrfs-progs
alles weitere unter
* [[Anleitung für Einsteiger]]


bitte genau nach Anleitung vorgehen, die fstab überprüfen. Diese sollte ungefähr so aussehen (hier ein EFI-SYSTEM)
  # mkdir /mnt/root/arch_pool
<br>
  # mkdir /mnt/root/home_pool
  # /dev/sda2 LABEL=ARCH
  # mkdir /mnt/snapshots
UUID=e3fdba80-b449-4266-8603-96691741c669      /                       btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@                                                    0 0
  # mkdir /mnt/arch/var
  # /dev/sda1
UUID=10F4-2424                                  /boot                  vfat    rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
  # /dev/sda2 LABEL=ARCH
UUID=e3fdba80-b449-4266-8603-96691741c669      /home                  btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@home                                                0 0
  # /dev/sda2 LABEL=ARCH
UUID=e3fdba80-b449-4266-8603-96691741c669      /var/cache/pacman/pkg  btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@pkg                                                  0 0
# /dev/sda2 LABEL=ARCH
UUID=e3fdba80-b449-4266-8603-96691741c669      /home/Amber/Daten      btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@daten                                                0 0
# /dev/sda2 LABEL=ARCH
UUID=e3fdba80-b449-4266-8603-96691741c669      /.snapshots            btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@snapshots                                            0 0
# /dev/sda3 LABEL=swap_arch
UUID=417b4d91-b330-4a29-9c26-a14935add34c      none                    swap    defaults
<br>
Selbstredend das die UUID anders ist oder Labels benutzt werden, je nach dem.<br>
Den Bootloader prüfen, die Linuxzeile muß angepasst werden mit rootflags=subvol=@. Unter grub sieht es so aus <br>
Beispiel = ''"linux  /vmlinuz-linux root=UUID=e3fdba80-b449-4266-8603-96691741c669 rw rootflags=subvol=@ quiet"''<br>
unter systemctl-boot so<br>
Beispiel = ''"root=LABEL=ARCH rootflags=subvol=@ rw quiet"''<br>
<br>
Wenn man sicher ist, alles korrekt ausgeführt zu haben, kommt nun der Neustart. Entfernen des Sticks und das neuinstallierte System fährt hoch.<br>
<br>
Ist das System hochgefahren werden jetzt erstmal snapshots erstellt, dreimal. Da jetzt im User-Modus gearbeitet wird brauche ich sudo
<br>
sudo btrfs subvolume create /.snapshots/WORKING
sudo btrfs subvolume create /.snapshots/STABLE
sudo btrfs subvolume create /.snapshots/OlDSTABLE
<br>
es werden noch ein Kernel und initramfs erzeugt mit einfachen kopieren
<br>
cp /boot/vmlinuz-linux /boot/vmlinuz-linux-stable
cp /boot/initramfs-linux.img /boot/initramfs-linux-stable.img
<br>
erstelle im Bootloader-Menü entsprechend zwei neue Einträge mit rootflags statt auf /@ auf /@snapshots/WORKING und auf /@snapshots/STABLE. Wobei im Menü auf /@snapshots/STABLE auch die entsprechenden kernel und initramfs stehen sollte, vmlinuz-linux-stable und initramfs-linux-stable.img. In der fstab in /.snapshots/WORKING/etc/fstab ändert man
diese Zeile:
<br>
UUID=e3fdba80-b449-4266-8603-96691741c669    /  btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@        0 0
<br>
in:
<br>
UUID=e3fdba80-b449-4266-8603-96691741c669    /  btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvol=@snapshots/WORKING  0 0
<br>
um. So arbeiten wir nach einen Neustart, entsprechende Auswahl nur noch mit dem subvolume WORKING. Bei Updates und Systemrollback ist es wichtig.<br>
'' Man kann einen passenden Menu-Abschnitt kopieren und das entscheidende ändern, wie rootflags oder linux-kernel.''<br>


Die diversen Scripte sind unter Scripte zu finden. Links folgen entsprechend.<br>
# btrfs subvol create /mnt/arch/var/cache
Ein Script "Snapshot-Rollback" kommt später."
# btrfs subvol create /mnt/arch/var/log
# btrfs subvol create /mnt/arch/var/spool
# btrfs subvol create /mnt/arch/var/tmp


''Danke an unicks.eu für die Video-Serie, die eine der wenigen ist, die es sehr anschaulich erklären''
# mkdir /mnt/home
''Teile von den Scripten stammen von unicks.eu''
# mount -o rw,noatime,compress=lzo /dev/sdb1 /mnt/home
# mkdir /mnt/home/snapshots
# mkdir /mnt/home/snapshots/BENUTZERNAME


have fun<br>
# btrfs subvol create /mnt/home/BENUTZERNAME
Gruß Amber
# btrfs subvol create /mnt/home/BENUTZERNAME/Dokumente
# btrfs subvol create /mnt/home/BENUTZERNAME/Downloads
# btrfs subvol create /mnt/home/BENUTZERNAME/Musik
# btrfs subvol create /mnt/home/BENUTZERNAME/Bilder
# btrfs subvol cr... usw. usf.


Weitere Informationen:
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.


* [[Update mit Snapshot]]
=== Weitere Installation ===
* [[Backup mit Rsync]]
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 der ''base''-Gruppe enthalten ist.
* [[Menue-Terminal]]
* [[UEFI Installation]]
* [[Fstab]]


=== 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,compress=lzo
UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=lzo
Die UUID für /, /root und /srv - sowie für /root/arch_pool - entspricht der UUID von /dev/sda1.
Die UUID für die /home/... - sowie für /root/home_pool - entspricht der UUID von /dev/sdb1.
Die UUIDs findest du beispielsweise mittels dem Befehl lsblk.
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 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 ===
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 {{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 (Einzeiler am besten als Script speichern):
$ echo $(date +%y_%m_%d)__$(( $(date +%s)-$(date -d 'today 0' +%s) ))
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:
# 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
# reboot
Hierdurch 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.
=== Subvolumen/Snapshots löschen ===
Subvolumen (Snapshots sind Subvolumen) mögen sich zwar in fast allen Aspekten wie Ordner verhalten, bleiben aber subvolumen. Subvolumen können, auch als root, nicht wie Ordner gelöscht werden:
# rm -rf SNAPSHOT
rm: cannot remove 'SNAPSHOT' : Operation not permitted
Stattdessen muss, wie bei der Erstellung von subvolumen, das entsprechende '''btrfs-progs''' Progamm genutzt werden:
# btrfs subvolume delete SNAPSHOT
Ergänzung: 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. - (Quellen: [https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature  Btrfs-Wiki] auf kernel.org, [https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#MOUNT_OPTIONS 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) [http://marc.merlins.org/perso/btrfs/post_2014-03-22_Btrfs-Tips_-Doing-Fast-Incremental-Backups-With-Btrfs-Send-and-Receive.html 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


[[Kategorie:Installation]]
[[Kategorie:Installation]]
[[en:Arch auf BtrFS]]
 
[[en:Btrfs]]

Version vom 20. Februar 2021, 21:56 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/GTP 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=lzo /dev/sda1 /mnt
# btrfs subvol create /mnt/arch
# btrfs subvol create /mnt/root
# btrfs subvol create /mnt/srv
# mkdir /mnt/root/arch_pool
# mkdir /mnt/root/home_pool
# mkdir /mnt/snapshots
# mkdir /mnt/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/tmp
# mkdir /mnt/home
# mount -o rw,noatime,compress=lzo /dev/sdb1 /mnt/home
# mkdir /mnt/home/snapshots
# mkdir /mnt/home/snapshots/BENUTZERNAME
# btrfs subvol create /mnt/home/BENUTZERNAME
# btrfs subvol create /mnt/home/BENUTZERNAME/Dokumente
# btrfs subvol create /mnt/home/BENUTZERNAME/Downloads
# btrfs subvol create /mnt/home/BENUTZERNAME/Musik
# btrfs subvol create /mnt/home/BENUTZERNAME/Bilder
# btrfs subvol cr... usw. usf.

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

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 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=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,compress=lzo
UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=lzo


Die UUID für /, /root und /srv - sowie für /root/arch_pool - entspricht der UUID von /dev/sda1. Die UUID für die /home/... - sowie für /root/home_pool - entspricht der UUID von /dev/sdb1. Die UUIDs findest du beispielsweise mittels dem Befehl lsblk.

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 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 (Einzeiler am besten als Script speichern):

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

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:

# 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
# reboot

Hierdurch 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.

Subvolumen/Snapshots löschen

Subvolumen (Snapshots sind Subvolumen) mögen sich zwar in fast allen Aspekten wie Ordner verhalten, bleiben aber subvolumen. Subvolumen können, auch als root, nicht wie Ordner gelöscht werden:

# rm -rf SNAPSHOT
rm: cannot remove 'SNAPSHOT' : Operation not permitted

Stattdessen muss, wie bei der Erstellung von subvolumen, das entsprechende btrfs-progs Progamm genutzt werden:

# btrfs subvolume delete SNAPSHOT

Ergänzung: 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. - (Quellen: Btrfs-Wiki auf kernel.org, 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