Arch auf BtrFS - Versionsgeschichte

Dirk am 21. März 2025 um 09:04 Uhr

2025-03-21T09:04:08Z

← Nächstältere Version		Version vom 21. März 2025, 11:04 Uhr
Zeile 57:		Zeile 57:
	# umount /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.		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-Verzeichnisse\|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		# mount -o rw,noatime,compress=zstd:3 /dev/sdb1 /mnt

Archlinuxusr: /* Partitionierung der Festplatte */

2022-02-17T15:41:10Z

Partitionierung der Festplatte

← Nächstältere Version		Version vom 17. Februar 2022, 17:41 Uhr
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~~/~~GTP~~ Setups benötigt GRUB eine BIOS BOOT Partition		* 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

BastardLawyerFromHell: /* Partitionierung der Festplatte */ Die Anleitung war inkonsestent bis zu meiner Änderung. Ohne das eingangs zu erstellende Subvolume /mnt/arch/root (anstelle /mnt/root) lassen sich die Ordner /mnt/arch/root/arch_pool und home_pool gar nicht anlegen.

2022-01-22T19:53:31Z

Partitionierung der Festplatte: Die Anleitung war inkonsestent bis zu meiner Änderung. Ohne das eingangs zu erstellende Subvolume /mnt/arch/root (anstelle /mnt/root) lassen sich die Ordner /mnt/arch/root/arch_pool und home_pool gar nicht anlegen.

← Nächstältere Version		Version vom 22. Januar 2022, 21:53 Uhr
Zeile 38:		Zeile 38:

	# 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/arch/srv		# btrfs subvol create /mnt/arch/srv

Casi: Pfad korrigiert ("/user/.. -> /usr/..")

2021-07-31T08:30:32Z

Pfad korrigiert ("/user/.. -> /usr/..")

← Nächstältere Version		Version vom 31. Juli 2021, 10:30 Uhr
Zeile 135:		Zeile 135:
	Anschließend noch die Permissions setzen:		Anschließend noch die Permissions setzen:

	# chmod 755 /~~user~~/local/bin/timestamp		# 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.

NorPhi: zstd wird mittlerweile von Grub unterstützt und ist performanter als lzo, daher besteht kein Grund mehr lzo zu verwenden.

2021-07-23T13:48:20Z

zstd wird mittlerweile von Grub unterstützt und ist performanter als lzo, daher besteht kein Grund mehr lzo zu verwenden.

NorPhi: /root sollte doch besser ein eigenständiges Subvolumen des btrfs-top-level Volumens sein, damit bleibt es bei einem Rollback erhalten. Die Subvolumen welche angelegt wurden um unnötigen Ballast aus dem Snapshots auszuschließen, müssen bei einem Rollback neu angelegt werden, dies fehlte. Bash scripts für timestamp und ballast_volumes.

2021-07-23T13:44:35Z

/root sollte doch besser ein eigenständiges Subvolumen des btrfs-top-level Volumens sein, damit bleibt es bei einem Rollback erhalten. Die Subvolumen welche angelegt wurden um unnötigen Ballast aus dem Snapshots auszuschließen, müssen bei einem Rollback neu angelegt werden, dies fehlte. Bash scripts für timestamp und ballast_volumes.

← Nächstältere Version		Version vom 23. Juli 2021, 15:44 Uhr
Zeile 38:		Zeile 38:

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

Zeile 97:		Zeile 97:
	# root file system /dev/sda1		# root file system /dev/sda1
	UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress=lzo		UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress=lzo
			UUID=... / btrfs rw,ssd,discard,noatime,subvol=root,subvolid=...,compress=lzo

	# user home directories /dev/sdb1		# user home directories /dev/sdb1
Zeile 125:		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 (~~Einzeiler am besten~~ als ~~Script speichern)~~:		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}}:

	$ echo $(date +%y_%m_%d)__$(( $(date +%s)-$(date -d 'today 0' +%s) ))		#!/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 /user/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 138:		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
	~~# 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.~~		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~~. ~~Subvolumen können~~, auch als root, nicht wie Ordner ~~gelöscht~~ werden:		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

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

	# btrfs subvolume delete SNAPSHOT		# 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)])		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 ==

NorPhi: Einteilung in Subvolumen vereinfacht. Wenn root und srv nicht im btrfs-top-level von /dev/sda1 liegen müssen diese nicht explizit eingehängt werden.

2021-07-23T02:01:27Z

Einteilung in Subvolumen vereinfacht. Wenn root und srv nicht im btrfs-top-level von /dev/sda1 liegen müssen diese nicht explizit eingehängt werden.

← Nächstältere Version		Version vom 23. Juli 2021, 04:01 Uhr
Zeile 38:		Zeile 38:

	# 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/root/arch_pool~~
	~~# mkdir /mnt/root/home_pool~~
	~~# mkdir /mnt/snapshots~~
	# 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

	# ~~mkdir~~ /mnt/home		# btrfs subvol list /mnt
	# mount -o rw,noatime,compress=lzo /dev/sdb1 /mnt~~/home~~
	# mkdir /mnt~~/home~~/snapshots		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~~/home~~/snapshots/BENUTZERNAME
			# 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=lzo /dev/sdb1 /mnt

			# mkdir /mnt/snapshots
			# mkdir /mnt/snapshots/BENUTZERNAME

	# btrfs subvol create /mnt~~/home~~/BENUTZERNAME		# btrfs subvol create /mnt/BENUTZERNAME
	# btrfs subvol create /mnt~~/home~~/BENUTZERNAME/Dokumente		# btrfs subvol create /mnt/BENUTZERNAME/Dokumente
	# btrfs subvol create /mnt~~/home~~/BENUTZERNAME/Downloads		# btrfs subvol create /mnt/BENUTZERNAME/Downloads
	# btrfs subvol create /mnt~~/home~~/BENUTZERNAME/Musik		# btrfs subvol create /mnt/BENUTZERNAME/Musik
	# btrfs subvol create /mnt~~/home~~/BENUTZERNAME/Bilder		# btrfs subvol create /mnt/BENUTZERNAME/Bilder
	# btrfs subvol cr... usw. usf.		# 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 {{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.		# btrfs subvol list /mnt

	~~'''useradd''' hat~~ die ~~flag '''---btrfs-subvolume-home''' um das home-Verzeichnis neuer User als~~ Subvolumen ~~anlegen zu lassen~~. ~~Ordner, welche als subvolumen gewünscht sind muss man aber dennoch händisch als subvolumen anlegen~~.		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.

	~~=== Weitere Installation ===~~		# umount /mnt
	Die BtrFS Partitionen sollten nun ausgehängt und als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann. Die zum einhängen der subvolumen benötigten IDs können mittels '''btrfs subvol list''' ermittelt werden, sollten aber beide 256 sein (immer die ID des ersten subvolumen). Sollten weitere Benutzer erstellt worden sein, weichen deren IDs jedoch ab.

	~~# btrfs subvol list~~ /~~mnt~~/~~arch~~		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.
	~~# btrfs subvol list~~ /~~mnt~~/home

	~~Nun da man sich der IDs versichert hat, können die subvolumen~~ eingehängt werden.		=== Weitere Installation ===
			Die BtrFS Partitionen sollten nun als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann.

	~~# umount /mnt/arch~~
	~~# umount /mnt/home~~
	~~# rmdir /mnt/arch /mnt/home~~
	# mount -o rw,noatime,subvol=arch,subvolid=256,compress=lzo /dev/sda1 /mnt		# mount -o rw,noatime,subvol=arch,subvolid=256,compress=lzo /dev/sda1 /mnt
	# mkdir /mnt/home/BENUTZERNAME		# mkdir /mnt/home/BENUTZERNAME
Zeile 93:		Zeile 97:
	# root file system /dev/sda1		# root file system /dev/sda1
	UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress=lzo		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		# user home directories /dev/sdb1
Zeile 104:		Zeile 106:


	Die UUID für /, ~~/root und /srv -~~ sowie für /root/arch_pool - entspricht der UUID von /dev/sda1.		Die UUID für '''/''', 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 UUID für die '''home'''-Verzeichnisse, sowie für '''/root/home_pool''', entspricht der UUID von /dev/sdb1.
	~~Die UUIDs findest du beispielsweise mittels dem Befehl~~ lsblk.		UUID ermittelt man mit '''lsblk -o NAME,UUID'''.
			Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit '''btrfs subvol list /'''.
	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.		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.

NorPhi: Abschnitt "Weitere Installation" beinhaltet nun dass man die BtrFS-Volumen aushängen und die entsprechenden Subvolumen einhängen muss.

2021-07-23T01:17:13Z

Abschnitt "Weitere Installation" beinhaltet nun dass man die BtrFS-Volumen aushängen und die entsprechenden Subvolumen einhängen muss.

@@ Zeile 64: / Zeile 64: @@
 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 ===
-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.
+Die BtrFS Partitionen sollten nun ausgehängt und als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann. Die zum einhängen der subvolumen benötigten IDs können mittels '''btrfs subvol list''' ermittelt werden, sollten aber beide 256 sein (immer die ID des ersten subvolumen). Sollten weitere Benutzer erstellt worden sein, weichen deren IDs jedoch ab.
 === fstab bearbeiten ===

Anonymous: Hint für die Ermittlung und Verwendung der UUIDs.

2021-02-20T20:56:54Z

Hint für die Ermittlung und Verwendung der UUIDs.

← Nächstältere Version		Version vom 20. Februar 2021, 22:56 Uhr
Zeile 86:		Zeile 86:
	UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress=lzo		UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress=lzo
	UUID=... /root/home_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:		Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit:

Anonymous: btrfs-top-levels soll nicht auf ein subvol verweisen, sondern auf das top level volume.

2021-02-20T20:55:43Z

btrfs-top-levels soll nicht auf ein subvol verweisen, sondern auf das top level volume.

← Nächstältere Version		Version vom 20. Februar 2021, 22:55 Uhr
Zeile 84:		Zeile 84:

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

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

← Nächstältere Version		Version vom 23. Juli 2021, 15:48 Uhr
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=~~lzo~~ /dev/sda1 /mnt		# mount -o rw,noatime,compress=zstd:3 /dev/sda1 /mnt

	# btrfs subvol create /mnt/arch		# btrfs subvol create /mnt/arch
Zeile 59:		Zeile 59:
	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.		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=~~lzo~~ /dev/sdb1 /mnt		# mount -o rw,noatime,compress=zstd:3 /dev/sdb1 /mnt

	# mkdir /mnt/snapshots		# mkdir /mnt/snapshots
Zeile 82:		Zeile 82:
	Die BtrFS Partitionen sollten nun als subvolume wieder eingehängt werden damit arch-chroot den mountpoint finden kann.		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=~~lzo~~ /dev/sda1 /mnt		# mount -o rw,noatime,subvol=arch,subvolid=256,compress=zstd:3 /dev/sda1 /mnt
	# mkdir /mnt/home/BENUTZERNAME		# mkdir /mnt/home/BENUTZERNAME
	# mount -o rw,noatime,subvol=BENUTZERNAME,subvolid=...,compress=~~lzo~~ /dev/sdb1 /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.		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.
Zeile 96:		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=~~lzo~~		UUID=... / btrfs rw,ssd,discard,noatime,subvol=arch,subvolid=...,compress=zstd:3
	UUID=... / btrfs rw,ssd,discard,noatime,subvol=root,subvolid=...,compress=~~lzo~~		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=~~lzo~~		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=~~lzo~~		UUID=... /root/arch_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3
	UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=~~lzo~~		UUID=... /root/home_pool btrfs noauto,rw,ssd,discard,noatime,compress=zstd:3


Zeile 112:		Zeile 112:
	Die subvolid sollte richtig eingelesen werden. Nachprüfen kann man mit '''btrfs subvol list /'''.		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.		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.

	=== Installation zu Ende führen und Bootloader installieren ===		=== Installation zu Ende führen und Bootloader installieren ===