snapper ein verzeichnis ausschliessen.

Deutsch (German) Installation/Administration
21

Backups sollten regelmässig ab einem virenfreien Bootmedium erstellt werden. Moderne USB-Wechselmedien sind so schnell, dass inkrementelle und differenzielle Backups überflüssig sind. Also in Privathaushalten immer brav und regelmässig Vollbackups auf USB-Wechselmedien erstellen. Siehe dazu:

Snapshots sind nützlich um rasch und unkompliziert versehentlich modifzierte oder gelöschte Dateien und Verzeichnisse wiederherzustellen. Für Snapshots sind unter Linux kein Btrfs (SUSE) oder ZFS (Ubuntu) erforderlich. Dank XFS Reflink kann man auch mit einer XFS-Partition eine den Snapshots entsprechende Funktionalität realisieren. Siehe dazu:
https://forums.opensuse.org/showthread.php/548533-btrfs-home-verzeichnis-sichtbar-machen-bei-boot-mit-anderem-betriebssystem

Es sollte auch klar sein, dass:

a) persönliche Daten auf eine eigenständige home-Partition gehören (üblich: /home).
b) Daten von Serverdiensten+Datenbanken auf eigenständige Datenpartitionen gehören (z.B. /opt)

dann enthält die root-Partition nur noch das Betriebssystem und die Programme. Was die root-Partition relativ klein hält (< 20 GB). Füllt ein Benutzer oder eine Benutzerin die home-Partition (dank fehlender “Disk Quota”), sollte das Betriebssytem nicht durch fehlenden Speicherplatz in seiner Funktionalität beeinträchtigt sein. Häufig wird von erfahrenen Administratoren für home- und Daten-Partitionen in der /etc/fstab spezielle Mount-Optionen wie noexec, nosuid eingesetzt, was die Sicherheit erhöhen (kann). Diese Mount-Optionen wären bei der root-Partition fehl am Platz.

Für einen möglichst stabilen Rechnerbetrieb sind einige Punkte zu beachten:

c) Nach Möglichkeit Einsatz von einer unterstützten** LTS-LInuxdistributionen** (> 5 Jahre Sicherheitsupdates): Red Hat Enterprise Linux und deren kostenlose Ablegern AlmaLinux und Rocky Linux, SUSE Linux Enterprise, sowie Ubuntu Server. Wer hat schon die Nerven und die Zeit sich freiwillig mit “Rolling Release”-Betriebssystemen wie zum Beispiel: OpenSUSE Tumbleweed, Microsoft Windows 10, Arch Linux, Gentoo Linux und FreeBSD rumzuärgern? Ob man OpenSUSE Leap ab Version 15 als kostenlosen Ableger von SUSE Linux Enterprise erachtet oder nicht, darf jeder Leser und Leserin für sich selber entscheiden. Je weniger Zeilen Programmcode geändert wird, desto unwahrscheinlicher ist das Auftreten von Softwareprobleme verursacht durch Regression.

https://en.wikipedia.org/wiki/Long-term_supportRegressionstest – Wikipedia

Angaben zu den aktuell unterstützten (Open)SUSE-Linuxdistributionen findet man unter:
https://en.opensuse.org/Lifetime

d) Nach Möglichkeit Einsatz von LTS-Softwareversionen anstelle der konventionellen Softwareversionen. Zum Beispiel Firefox ESR statt Firefox. Siehe dazu:
https://forums.opensuse.org/showthread.php/555850-Mozilla-Firefox-90-unleserliche-Inhalte?p=3066600#post3066600
Auch hier wieder: Je weniger Zeilen Programmcode geändert wird, desto unwahrscheinlicher ist das Auftreten von Softwareprobleme verursacht durch Regression.
https://de.wikipedia.org/wiki/Regressionstest

e) Alle Dateien, welche der Administrator respektive die Administratorin mit root-/Administrator-Rechte in die root-Partition einbringt oder verändert, müssen einer Versionskontrolle unterstehen. Es muss immer nachvollziehbar sein, wer, was, wann, wie auf der root-Partition modifiziert hat. Im wesentlichen sind die Konfigurationsdateien und selbst erstellten Programme und Shellskripte unter Versionskontrolle zu bringen. Selbst erstellte Konfigurationsdateien, Programme und Shellskripte kann man mit Git verwalten. Selbst sprechend sind diese Git-Repositories auf mehreren Datenträger abzulegen (=> Thema “Backup”). Alle Konfigurationsdateien und Shellskripte, die nicht bereits in einem offiziellen RPM enthalten sind, sollten auf den Linux-Rechnern per selbst erstelltem Softwarepaket verteilt und installiert werden (SUSE und RedHat: RPM; Ubuntu: DEB).

f) Minor- und Major-Upgrades gemäss:
https://en.opensuse.org/Lifetime
müssen vor der Installation auf dem Produktivsystem auf einer hardware- und softwaremässig identischen Testumgebung ausgiebig getestet werden. In der Testphase müssen auch die selbst erstellten und modifizerten Konfigurationsdateien, Programme und Shellskripte allenfalls für dieses Upgrade angepasst und getestet werden. Minor-Upgrades darf man bei RedHat und SUSE Linux Enterprise und deren kostenlosen Abkömmlinge einmal jährlich erwarten. Major-Upgrades darf man bei RedHat, SUSE Linux Enterprise, Ubuntu Server und deren kostenlosen Abkömmlinge einmal alle 5 bis 10 Jahren erwarten. Eine hardwaremässig identische Testumgebung ist ja sowieso erforderlich und sollte vorhanden sein, damit man im Fall eines Hardwaredefekts rasch die defekte Hardware ersetzen kann.

Bei Major-Upgrades empfehle ich das vollständige Löschen der Festplatte oder SSD per “Secure Erase”. Damit allenfalls vorhandene Schadsoftware (Virus) das Major-Upgrades NICHT übersteht. Mit diesem Vorgehen wird auch regelmässig das Backupverfahren und dessen Restore getestet. Beim Major-Upgrades sollte auch gleich das root-Passwort geändert werden.

Für das Einspielen von Minor- und Major-Upgrades auf Produktivsystemen muss ein Drehbuch erstellt werden. Das Drehbuch wird während dem Testen auf der Testumgebung erstellt.

g) Auf dem Produktivsystem sollten nur nicht-sicherheitsrelevante Softwareupdates installiert werden, welche vorgängig auf der Testumgebung ausgiebig getestet wurden. Sicherheitsrelevante Softwareupdates sollten rasch möglichst installiert werden. Ob man sicherheitsrelevante Softwareupdates vor der Installationsfreigabe auf der Testumgebung testen will oder nicht, ist dem Administrator überlassen. Zum Einspielen von sicherheitsrelevanter Softwareupdates unter OpenSUSE oder SUSE Linux Enterprise siehe auch (Seite 2 beachten!):
https://forums.opensuse.org/showthread.php/547458-Softwareupdates-(im-Allgemeinen)

h) Alle Modifikationen der root-Partition durch den Adminstrator sind in einem oder mehreren Logbüchern zu protokollieren. Als Logbuch erachte ich auch die Logdatei /var/log/zypp/history, welche alle durch zypper durchgeführte Softwareupdates und Softwareinstallationen protokolliert. Diese Logdatei ist am bequemsten im YAST2-Modul “Software installieren oder löschen” per Menüpunkt “Verlauf anzeigen” einsehbar.

Werden alle oben genannte Punkte strikt eingehalten, erübrigt sich aus meiner Sicht der Einsatz von Snapper.

22

Die Praxis ist glücklicherweise wesentlich einfacher als die tönerne Theorie. btrfs bietet die ultimative Flexibilität und Funktionalität.

Beispiel Backup von /home (sda2) auf /backup-home (sdb13):

**i3-4130:~ #** fdisk -l /dev/sda2 /dev/sdb13 
**Disk /dev/sda2: 134.74 GiB, 144676225024 bytes, 282570752 sectors**
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 4096 bytes 
I/O size (minimum/optimal): 4096 bytes / 4096 bytes 


**Disk /dev/sdb13: 48.83 GiB, 52428800000 bytes, 102400000 sectors**
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
**i3-4130:~ #**

Subvolume home auf sda2

**i3-4130:~ #** btrfs subvolume show -r 263 / 
@/home 
        Name:                   home 
        UUID:                   886ff6be-d0f6-c743-bf97-5ced16ab11b9 
        Parent UUID:            - 
        Received UUID:          - 
        Creation time:          2020-07-13 16:59:01 +0200 
        Subvolume ID:           263 
        Generation:             118935 
        Gen at creation:        24 
        Parent ID:              256 
        Top level ID:           256 
        Flags:                  - 
        Send transid:           0 
        Send time:              2020-07-13 16:59:01 +0200 
        Receive transid:        0 
        Receive time:           - 
        Snapshot(s): 
                                @/home/backup_0 
                                @/home/backup_1 
                                @/home/backup_2 
                                @/home/backup_3 
                                @/home/backup_4 
                                @/home/backup_5 
        Quota group:            0/263 
          Limit referenced:     - 
          Limit exclusive:      - 
          Usage referenced:     3.88GiB 
          Usage exclusive:      235.20MiB 
**i3-4130:~ #**

Subvolumes auf sdb13:

**i3-4130:~ #** btrfs subvolume list -t /backup-home 
ID      gen     top level       path 
--      ---     ---------       ---- 
256     19      5               backup_0 
258     26      5               backup_1 
259     30      5               backup_2 
260     35      5               backup_3 
261     39      5               backup_4 
262     42      5               backup_5 
**i3-4130:~ #**

Backups erfordern keine zusätzliche Software sondern können ratz fatz aus dem Handgelenk gemacht werden:

**i3-4130:~ #** btrfs subvolume snapshot -r /home /home/backup_6 
Create a readonly snapshot of '/home' in '/home/backup_6' 
**i3-4130:~ #** btrfs send -p /home/backup_5 /home/backup_6 | btrfs receive /backup-home               
At subvol /home/backup_6 
At snapshot backup_6 
**i3-4130:~ #**

btrfs minimiert den Aufwand. Es liefert einen vollständigen Backup zum Preis eines inkrementellen Backups.