Es gäbe da im Ablauf ein paar Optimierungsmöglichkeiten. Allerdings gäbe es zuerst die Frage, warum alle Welt immer auf Imaging setzt.
Mein Vorschlag zur Optimierung wäre ein hybrides Verfahren.
Punkt 1: Aufteilung der SSD in mehrere kleinere Partitionen (das ist unter GNU/Linux sehr üblich, eine überschaubar kleine / Partition, eine weitere Partition, die unter /var eingebunden wird, eine für /tmp, eine für /boot, eine für /home. Man kann die Aufteilung auch beliebig anders gestalten.
Typisch wäre aber, die / Partition ca. 8 GByte groß zu machen, /var vielleicht auch noch mal 8 GByte, /boot vielleicht nur 500 MByte usw.
Nun kann man die einzelnen Partitionen in kürzerer Zeit klonen. Eingehängte Partitionen werden dabei nicht mit geklont, denn sie sind ja nicht Bestandteil der Partition.
Sinnvoll ist das Klonen vor allem für /boot, / und /var. /tmp kann man getrost weg lassen. /home könnte man auch über klonen sichern, einfacher wäre es aber, die entsprechenden Verzeichnisse mit rsync bzw. mit rsnapshot zu sichern.
Man richtet auf jedem Rechner, von dem Backups gezogen werden sollen rsync ein. Auf dem Rechner, der die Backups speichern soll, richtet man zusätzlich zu rsync noch rsapshot ein. Dort hinterlegt man auch die Informationen, welche Verzeichnisse auf den jeweiligen Systemen gesichert werden sollen.
Der Sicherungsvorgang wird dann z.B. viertelstündlich, stündlich, täglich, wöchentlich und monatlich ausgeführt. Beim Backup werden aber nur die Dateien übertragen, welche sich seit dem letzten Backup geändert haben. Initial dauert ein solches Backup also z.B. bei 8 GByte und 8 MByte/s etwa 20 Minuten, anschließend aber, bei typischerweise Änderungen von wenigen KByte auch nur wenige Sekunden.
Auf dem Backup Server gibt es dann pro System ein Verzeichnis, in dem Verzeichnis pro Snapshot ein weiteres Verzeichnis, und in jedem dieser Verzeichnisse ein vollständiges Backup des Zeitpunkts. Dabei nehmen aber nur die Dateien "zusätzlich" Platz weg, die sich geändert haben (das geht mit Hardlinks extrem elegant).
Als Lohn der Arbeit hat man also vollständige Backups für die z letzten Viertelstunden, für die y letzten Stunden, die x letzten Tage, die w letzten Wochen und die v letzten Monate. Man kann also notfalls sehr alte Stände von Dateien wiederherstellen, ist aber auch bei mehreren Änderungen in kurzer Zeit noch in der Lage, Zwischenstände zu nutzen. Und das mit minimalem Platzbedarf.
Da der Backup Server die Daten im Pull-Verfahren zieht, ist diese Vorgehensweise sogar hilfreich bei Verschlüsselungstrojanern (vorausgesetzt, das Backupsystem ist nicht selbst kompromittiert).
Die Sicherung mit rsnapshot bietet sich dann durchaus auch für ganz bestimmte Verzeichnisse auf den Partitionen an, die man komplett klont, also z.B. /etc/openhab/ oder /var/lib/openhab/.
So kann man dann die entsprechenden Partitionen in längeren Abständen klonen und in erträglicher Zeit dennoch zum aktuellen Stand zurück kommen.
Ein kompletter Restore läuft dann so ab, dass man die letzten Partitionen über den konventionellen Weg zurück spielt und anschließend einmal die Dateien aus den Snapshots über die vorhandenen Dateien (gerne mit der Option, nur ältere Dateien zu überschreiben, womit die Übertragung nochmals kürzer läuft)
Imaging mit großen Partitionen ist in den seltensten Fällen wirklich sinnvoll
Ach so... Es ist natürlich wichtig, da hier nur Teile der Platte geklont werden, die Partitionsliste ebenfalls zu sichern. Die muss dann bei neuen Platten zuerst aufgepielt werden (oder man muss alternativ manuell eine Partitionsliste erstellen, in der jede der Partitionen mindestens so groß ist, wie die Quellpartitionen.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
#
