Welchen Vorteil hat es denn heute noch, /home auf einer anderen Partition zu packen?
Es hatte noch nie einen riesen Vorteil. Die Idee war ursprünglich mal, dass mal das OS neu installieren konnte und das Homeverzeichnis erhalten blieb. Wen das nicht interessiert hat, für den macht das auch keinen Sinn. Generell hab ich nie wirklich verstanden wieso manche Leute meinten sie müssten sich 10 Partitionen anlegen und jedes zweite Verzeichnis als eigene Partition laufen lassen. Das macht vielleicht auf Server ein klein wenig Sinn, aber auf Desktops oder Notebooks? Manches muss man nicht verstehen.
Ich hab das inzwischen so gelöst, dass ich zwei Partitionen hab, eine ESP und eine große LUKS2-verschlüsselte Partition. In dieser wiederrum ist eine VG mit zwei LVs, einmal "root" und einmal "swap". Das hab ich deshalb so, weil man ansonsten gleich zwei LUKS-Partitionen entschlüsseln müsste, damit Suspend-To-Disk funktioniert, und das ist einfach nur nervig.
Die root-VG hat ein Btrfs-Dateisystem mit zwei Subvolumes, "@" und "@home", die in "/" und "/home" gemountet sind. Das Toplevel-Subvolume ist wiederrum in "/.toplevel" gemountet, damit ich Snapshots von beiden Subvolumes machen kann, die wiederrum nicht in dem Subvolume sind, was ich snapshotten möchte, denn das macht einen Rollback nervig. Die Snapshots befinden sich in "/.toplevel/snapshots/<Subvolumename>/YYYY-MM-DD HH:MM:SS" und werden von einem Pacman-Hook und einem systemd-Timer angelegt. Der Timer startet einen Service, der mein Homeverzeichnis 5 Minuten nach dem Boot (1 Min randomized) und dann jeweils eine Stunde (1 Min randomized) nach der letzten Deaktivierung des Services (also nach der Fertigstellung des Snapshots). Der Pacman-Hook ist ein PreTransaction-Hook (also bevor etwas auf dem Dateisystem geändert wurde mit Ausnahme des Paketdownloads) und snapshotted mir mein "/"-Subvolume. Abgelegt werden die Snapshots auf der Backup-SSD dann in "<mountpoint>/.snapshots/<hostname>_<machine-id>/<Subvolumename/YYYY-MM-DD HH:MM:SS". Dadurch sind die Snapshots (A) versteckt, heißt man kann die SSD gut auch noch für Datenaustausch benutzen, und (B) man kann die SSD für Backups mehrerer Systeme benutzen.
Diese Snapshots funktionieren, ähnlich wie Apple Time Machine, nur dann, wenn eine externe SSD mit einer bestimmten UUID gemounted ist. Heißt es ist wirklich ein Backup und nicht nur eine Dateisystem-Historie. Ist die Backup-SSD nicht gemounted, schlagen Paketinstallationen mit Pacman fehl, was mich selbst praktisch dazu zwingt die SSD anzuklemmen, bevor ich Updates mache.
Das funktioniert jetzt so schon seit einem halben Jahr absolut ausgezeichnet. Dadurch, dass ich den letzten Snapshot nicht nur auf der Backup-SSD, sondern auch auf der Arch-SSD habe (zwecks inkrementeller Snapshots), kann ich auch ohne die Backup-SSD mit dabei zu haben auf maximal einen Stand in der Vergangenheit zurückspringen, indem ich einfach eins oder beide der Subvolumes in "/.toplevel" umbenenne und mir dann einen Snapshot aus dem Snapshot in "/.toplevel/snapshots" mache. Will ich auf einen noch älteren Stand zurückspringen, zieh ich mir einen Snapshot von der Backup-SSD. Falls das OS mal aus irgendeinem Grund nicht mehr bis zu GDM durchbootet, hab ich den "btrfs"-Hook in der initramfs. Kann dann einfach in die Emergency-Shell der systemd-initramfs booten, die Root-Partition mounten und dort dann das Gleiche mit den Subvolumes machen wie auch in dem gebooteten OS.
Wenn ich das Script für die Snapshots mal ein bisschen "dynamischer" gemacht hab und auch mal eine Möglichkeit gefunden habe Snapshots zu löschen, wenn die Backup-SSD voll ist, dann teil ich das hier.