openhabforum.de

Hallo,

mein OH3 läuft derzeit auf einer SSD. Wie kann ich am einfachsten ein volles Backup realisieren?

Als es noch auf SD Karte lief, habe ich es wie folgt gemacht:
Raspi herunterfahren, SD Karte entnehmen, SD Karte in Windows PC einlegen u. Datensicherung mit Win32Diskimager durchführen.

Ich habe mich bereits mit Amanda Backup beschäftigt, aber das erscheint mir als viel zu kompliziert. Der Einrichtungsaufwand ist mir ehrlich gesagt zu komplex. Blicke an vielen Stellen der Dokumentation überhaupt nicht durch.

Gibt es da einen einfacheren Weg?

Es kommt sehr darauf an, was Du drum herum zur Verfügung hast, und wie die SSD eingerichtet ist. Gewöhnlich maximiert das Installationsscript die zweite Partition auf der SD-Karte bis zum Ende. Vermutlich ist das bei Deiner SSD auch nicht anders. Allerdings wäre es bei einer SSD normaler Größe (alles über 32 GB definitiv, aber auch schon bei 16 GB) wesentlich sinnvoller, die SSD in mehrere Partitionen aufzuteilen, z.B. /boot, / und /space, wobei /space dann jederzeit in / an irgendeiner Stelle eingehängt werden kann. Der Witz dabei ist, dass egal, wie man ein Backup erstellt, man dafür sorgen kann, dass der Einhängepunkt nicht verfolgt wird. Man kann also das komplette Backup in /space weg schreiben und auch von dort z.B. auf einen externen Datenträger kopieren.
Hast Du ein NAS, so schreit alles danach, das Backup per rsync vorzunehmen, bestenfalls mit rsnapshot. rsnapshot kopiert die Daten (am besten über Netzwerk) auf das Backupmedium. Der Knackpunkt: rsnapshot bedient sich dabei rsync. Es werden lediglich Dateien übertragen, die sich geändert haben, und es wird nur die Differenz übertragen. Die Datei wird am Zielort nicht überschrieben, sondern es wird eine neue Kopie angelegt. Vorher wird ein komplettes Abbild des gesicherten Verzeichnisses angelegt.Aber auch hier kommt ein Trick zum Einsatz, und zwar arbeitet rsnapshot hier mit Hardlinks. Das heißt, wenn Du in ein Backup schaust, siehst Du immer eine vollständige Sicherung mit allen Dateien.
Dateien, die sich von Backup zu Backup nicht geändert haben, nehmen aber nur einmal Platz weg.
Dateien, die sich geändert haben, nehmen für jede Kopie einmal den Platz in Anspruch. Es gibt natürlich Dateien, die extrem volatil sind, die sollte man von solchen Backups ausschließen (logs z.B.) aber alles, was auch nur im geringsten mit Konfiguration zu tun hat, kann man so sichern, und zwar üblicherweise im Viertelstundentakt. rsnapshot verwendet eine ähnliche Strategie wie rrd4j, es sichert (konfigurierbar) viertelstündlich, stündlich, täglich, wöchentlich, monatlich. Für jede der Stufen kann man eine Anzahl aufzuhebender Kopien angeben. Und zu jedem der gesicherten Zeitpunkte kommt man ganz einfach zurück, weil man einfach nur das entsprechende Verzeichnis mit seinem Inhalt zurück kopieren muss. Und da man immer das vollständige Dateisystem vor sich hat, kann man auch ganz leicht auf einzelne Dateien zugreifen, ohne sich irgendwelche Gedanken zu machen.

Amanda kann auch Images von der Platte herstellen, das könnte man notfalls auch mit dd per Hand machen (oder mit einem selbst gedengelten Script, ist letztlich nur ein Einzeiler) aber gerade der Weg zurück ist dann immer sehr steinig. Bei Kopien auf Dateiebene kannst Du Dich jederzeit ganz einfach davon überzeugen, dass die Dateiinhalte korrekt sind (zumindest solange es sich um Text handelt...) bei Images musst Du mindestens das Image irgendwo einhängen, um Dich von der Unversehrtheit zu überzeugen.

Der Weg zurück: Du spielst einfach das Original Image auf (welches zu dem Zeitpunkt aktuell ist...) und kopierst anschließend die Konfiguration zurück. Dabei muss man nur im Ausnamhefall mit Stolpersteinen rechnen, z.B. funktionierte nach einem Update von 3.2 auf 3.3 plötzlich das Log nicht mehr. Des Rätsels Lösung: die Konfiguration wird nun in einer anderen Datei vorgehalten, in der Originaldatei steht nur noch ein Link auf die neue Datei. Das Format ist ebenfalls ein anderes, so dass es beim Austausch der Originaldatei dann zu Störungen kommen kann. So etwas ist aber definitiv die Ausnahme.

DavGre hat geschrieben: ↑8. Aug 2022 18:43 Wie kann ich am einfachsten ein volles Backup realisieren?

raspiBackup kann nicht nur von einer SD, sondern auch von einer SSD ein Backup machen:

https://www.linux-tips-and-tricks.de/de/installation/

Danke für eure Hilfe-

Ich habe gerade leider festgestellt, dass ich die SSD nicht partioniert habe. Wenn ich jetzt mit Win32DiskImager ein Image erstelle, ist das satte 120 GB groß. Das wird ja dann bei RaspiBackup auch der Fall sein, oder?

Dann würde es ja als erstes Sinn machen, Partitionen auf der SSD einzurichten, oder? Falls ja, geht das nachträglich noch?

Na, die SSD wird vermutlich schon zwei Partitionen haben.
Das kannst Du mit mount überprüfen sehen, die erste Partition ist dann /boot/ und die zweite Partition /

Man kann die Partition / auch nachträglich ändern, allerdings ist das, da es sich um die Root Partition handelt, nicht ganz so einfach.

Der bei weitem einfachste Weg wäre, ein Live Linux zu starten und gparted zu verwenden. Das geht ja relativ bequem mit jedem PC der von USB booten, oder gar noch ein antiquiertes ( ) DVD Laufwerk zum booten nutzen kann.

Wenn Du es ordentlich machen möchtest, wäre der vernünftigste Weg, das System komplett neu aufzusetzen und bei dieser Gelegenheit lvm zu aktivieren. Mit lvm (Logical Volume Manager) stehen nette Funktionen zur Verfügung, die das Leben einfacher machen können, z.B. Snapshots.
Man erstellt einen Snapshot und gibt eine maximale Größe für diesen Snapshot an, z.B. 1GByte. Der Zustand der Partition wird nun eingefroren und jegliche Änderung erfolgt nur noch auf dem 1 GByte Bereich. Das geht natürlich nicht lange gut, aber weit ausreichend, um ein Image des Snapshots wegzuschreiben. Anschließend wird der Snapshot gelöscht und damit der reservierte Bereich mit dem alten Stand zusammengeführt (durch Umsortieren der Blöcke...) Beide Vorgänge dauern unabhängig von der Partitionsgröße auf einem Raspberry nur wenige Sekunden.
Der Punkt ist, dass der Snapshot eben "eingefroren" ist, somit finden keinerlei Veränderungen am Dateisystem statt, die vielleicht sonst zu einer Inkonsistenz führen könnten. Images von Snapshots sind praktisch immer fehlerfrei bootfähig.

Ansonsten kannst Du mit lvm Partitionen nach Herzenslust im laufenden Betrieb anlegen, löschen, ändern... nur die root Partition kann nicht im laufenden Betrieb verkleinert werden, alle anderen Aktionen sind möglich. Wenn Du ein debian auf einem Raspberry einrichtest, bringt der Installer die Routinen zum automatischen Einrichten mit. Bei Raspberry Pi OS (lite) muss man hingegen manuell nachhelfen, das ist dann eher was für Fortgeschrittene.

DavGre hat geschrieben: ↑10. Aug 2022 12:15 Das wird ja dann bei RaspiBackup auch der Fall sein, oder?

Nein.

Es kommt darauf an welche Methode du nutzt, eine Übersicht findest du hier unter "Backupmethode":

https://www.linux-tips-and-tricks.de/de/raspibackup/

Bei dd ist das Backup genauso groß wie die Platte, bei tar deutlich kleiner und auch raspiBackup kann rsync nutzen, so dass hier nur beim ersten Mal alle Dateien gesichert werden und in folgenden Backups nur noch die geänderten Dateien.

Das von udo1toni angesprochene Vorgehen mit gparted habe ich hinbekommen. Die Partition mit OH ist nun nur noch 30 GB groß.
Ich würde dann zunächst die dd-Variante mit raspibackup anstreben, da das restoren so abläuft, wie ich es bisher immer gemacht habe.

Das sollte mit einem entsprechend großen USB Stick doch möglich sein, oder?

Ja, durchaus.

tar wird entweder auch auf Dateiebene arbeiten oder auch ein Image beinhalten, was dann aber z.B. mit gzip verkleinert wurde.