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:
https://community.upc.ch/d/19812-dro...en-downloads/4
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/showthre...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://de.wikipedia.org/wiki/Rolling_Release
https://en.wikipedia.org/wiki/Long-term_support
https://de.wikipedia.org/wiki/Regressionstest
Angaben zu den aktuell unterstützten (Open)SUSE-Linuxdistributionen findet man unter:
https://en.opensuse.org/Lifetime
https://www.suse.com/lifecycle/
d) Nach Möglichkeit Einsatz von LTS-Softwareversionen anstelle der konventionellen Softwareversionen. Zum Beispiel Firefox ESR statt Firefox. Siehe dazu:
https://forums.opensuse.org/showthre...00#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/showthre...m-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.
