Page 3 of 3 FirstFirst 123
Results 21 to 22 of 22

Thread: snapper ein verzeichnis ausschliessen.

  1. #21

    Default AW: Re: AW: Re: snapper ein verzeichnis ausschliessen.

    Quote Originally Posted by karlmistelberger View Post
    Backups herkömmlicher Art leiden unter dem klassischem Dilemma:
    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.

  2. #22
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    3,994

    Default Re: AW: Re: AW: Re: snapper ein verzeichnis ausschliessen.

    Quote Originally Posted by GrandDixence2 View Post
    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.
    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):
    Code:
    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
    Code:
    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:
    Code:
    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:
    Code:
    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.
    i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), 5600X (2022) openSUSE Tumbleweed, KDE Plasma

Page 3 of 3 FirstFirst 123

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •