FHEM-Backup via Netzwerk auf NAS für Anfänger?

Begonnen von Dracolein, 05 Dezember 2022, 09:41:09

Vorheriges Thema - Nächstes Thema

Dracolein

Hallo zusammen,

dieser Thread von mir zum Thema "Haltbarkeit SD-Karte" ist 3 Jahre alt (https://forum.fhem.de/index.php/topic,106343.45.html). Inzwischen ist meine FHEM Installation zu einer beachtlichen Instanz gewachsen und führt durchaus wichtige Aufgaben im Hause durch. Mitunter vergangene Woche gab es einen Crash bei mir, ausgelöst durch ein veraltetes GasCalculator Modul, was ich dank Forenhilfe schnell beheben konnte und womit auch ein "Real-Life-Test" meiner Backupstrategie durchgespielt wurde. Hier dran möchte ich nun etwas ändern / verbessern.

Kurzum zu den Rahmenbedingungen:
- FHEM läuft lokal auf Raspberry Pi 4 mit 32GB Sandisk Extreme SD-Karte
- ConBee II USB Stick mit deCONZ und größerem Zigbee-Netzwerk ist lokal angeschlossen und in FHEM genutzt
- Das Betriebssystem enthält einen gemounteten Netzwerkpfad zu meiner Synology Diskstation (weiß gar nicht mehr, nach welcher Anleitung ich das damals realisiert habe)
- Auf der Synology existiert ein raspi-User, der Lese- und Schreibzugriff auf einen Unterordner hat
- Alle meine Filelog-Device Logfiles sind dort abgelegt (--> verringert die Schreibzugriffe auf die lokale SD-Karte)
(- Meine Synology enthält eine imho relativ taugliche Backup-Strategie (RAID 1 gegen HDD-Ausfall + tägl. Backup auf zweite Synology + monatlich separates Backup + monatlicher Cloud-Upload wichtigster Daten usw))

Aktuell sichere ich 1x monatlich die SD Karte lokal mittels SD-Card-Copier und teste selbige Ersatz-SD Karte anschließend auf Funktion. Ist umständlich, erfordert Disziplin, bedingt rund 20 Minuten Ausfallzeit, aber auch die Gewissheit, jederzeit eine komplett funktionale Ersatzkarte liegen zu haben. Das mache ich seit rund 2 Jahren und hatte nie ein Problem.
Übrigens hatte ich seit Dezember 2019 (oben verlinkter Thread) keinen SD-Karten Ausfall mehr.

Nun habe ich diverse Infos im Forum gefunden, wie Ihr eure FHEM Instanzen automatisiert sichert. Die Krux bei mir ist: ich traue mir mangels ausreichender Linuxkenntnisse nicht zu, ein solches Backup inklusive allem drum und dran wieder sauber einzuspielen. (Drum auch mein persönlicher Workaround mit obiger zweiter SD-Karte)
Im worst Case hätte ich inzwischen einen 30 Tage alten Datenstand beim Crash, was erträglich, aber nicht so schön wäre. 
Deshalb möchte ich gern fragen, ob es Möglichkeiten inkl Anleitungen gibt, wie jemand wie ich eine automatisierte Backupstrategie realisieren kann, die bezogen auf den Raspberry Pi allumfassend ist. In meiner naiven Vorstellung wird z.B. 1x täglich der gesamte SD-Karteninhalt auf meiner Synology abgespeichert und lässt sich bei Bedarf mittels Cardreader an einem (Windows)PC "irgendwie" auf eine frische SD-Karte aufspielen, die ich nach Abschluss einfach 1:1 am Raspi auswechseln kann.  Geht das ggf?
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Frank_Huber

Moin,

ich sichere einmal täglich FHEM mittels "backup" Befehl auf einen Netzwerkspeicher.
Zwei mal monatlich mache ich ein SD Karten Image. Nachts vollautomatisch im laufenden Betrieb.
dafür habe ich mir mal eine sh Datei zusammenkopiert. manch einer mag online image ziehen nicht wegen der Gefahr geöffneter Dateien.
Bisher haben alle Restore Tests aber einwandfrei funktioniert. Ich kann Dir das später gerne hier einstellen.


Grüße
Frank

MadMax-FHEM

#2
Zitat von: Dracolein am 05 Dezember 2022, 09:41:09
Nun habe ich diverse Infos im Forum gefunden, wie Ihr eure FHEM Instanzen automatisiert sichert. Die Krux bei mir ist: ich traue mir mangels ausreichender Linuxkenntnisse nicht zu, ein solches Backup inklusive allem drum und dran wieder sauber einzuspielen. (Drum auch mein persönlicher Workaround mit obiger zweiter SD-Karte)

Selbst erarbeiten ist schwer aber du verstehst wie es geht/gehen soll und du verstehst es usw.
Egal wie gut eine Anleitung scheint (bzw. fast anders: je besser/einfacher eine Anleitung scheint, am Ende noch mit autom. Script was alles einrichtet usw.) wenn du nicht GENAU verstehst was da passiert usw.: taugt das nicht

Und: Backup wird oft erläutert und meistens sind Backups vorhanden aber keine Idee, wie man das zurück spielt/zurück spielen soll -> Restore ist wichtig und muss geübt werden!


Zitat von: Dracolein am 05 Dezember 2022, 09:41:09
Im worst Case hätte ich inzwischen einen 30 Tage alten Datenstand beim Crash, was erträglich, aber nicht so schön wäre. 
Deshalb möchte ich gern fragen, ob es Möglichkeiten inkl Anleitungen gibt, wie jemand wie ich eine automatisierte Backupstrategie realisieren kann, die bezogen auf den Raspberry Pi allumfassend ist. In meiner naiven Vorstellung wird z.B. 1x täglich der gesamte SD-Karteninhalt auf meiner Synology abgespeichert und lässt sich bei Bedarf mittels Cardreader an einem (Windows)PC "irgendwie" auf eine frische SD-Karte aufspielen, die ich nach Abschluss einfach 1:1 am Raspi auswechseln kann.  Geht das ggf?

Ich würde lieber eine Backup-Strategie wählen (und habe ich auch), die unabhängig von der Plattform ist.
Ergo: kein Komplett-Image (und schon gar nicht während das System läuft: kann inkonsistent werden/sein EDIT: ja ich bin "manch einer" 8)  )

Weil dadurch kommt man (vermeintlich) schnell wieder auf die Füsse aber: wie kommt man auf eine neue HW-Plattform (mit anderer Prozessor-Architektur) und neue/andere OS-Version?

Bei meiner "Strategie" macht es keinen (kaum einen) Unterschied, ob ich auf dieselbe Plattform restore oder komplett neu (HW und OS).

Ich sichere fhem mittels backup und kopiere das automatisch per Script auf ein NAS inkl. mount/unmount (nicht direkt/dauerhaft gemountet, weil ich so prüfen kann, ob tatsächlich gemountet ist usw. / wenn der Mount mal weg ist usw., dass ist das Backup lokal oder gar nicht angelegt oder oder oder).
Das einmal pro Woche, könnte ich öfter machen aber so oft ändere ich nicht.
(monatlich dann auf ein weiteres NAS)
Oder manuell, wenn ich doch mal größere Dinge umbaue und die letzte Sicherung ist gerade erst her...

Parallel schreibe ich mit, welche Pakete ich installiere und warum.
EDIT: dann kann (und mache ich auch) ich bei einer Neuinstallation/Restore überlegen, ob ich das noch brauche/will...
Ebenso Vorbereitungsschritte für z.B. "Aufsteckmodule" usw.

Mache ich so seit 6+ Jahren und seit ca. 4 Jahren automatisiert (per Script).
Und bin schon einige Male umgezogen: PI2 -> PI3 und Wheezy -> Jessie -> Stretch -> Buster -> Bullseye

Und ja auch schon nach einem SD crash.

Seit einigen Jahren laufe ich deshalb von SSD...

Ja habe auch schon überlegt weitere Dinge bei Restore in ein Script zu packen aber das spart nur wenig Zeit und wenn sich bei einer neuen OS-Version etwas ändert, dann hilft das Script auch nicht immer, weil es Fehler gibt (wenn man "Glück" hat) oder das Script läuft durch und trotzdem geht etwas nicht (zu "schlechte" Fehlerabfrage im Script).

Da ich bei einem Umzug/nach einem Crash ein langlaufendes, stabiles System haben will, nehme ich mir die paar Minuten und mache Einiges beim Restore bewusst manuell...

Nur meine Meinung dazu...
(und RAID ist kein Backup aber das hast du ja erkannt :)  )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wernieman

#3
@Frank_Huber
Gerade für Linux Anfänger ist "Image im Laufenden Betrieb" das Problem. Genau dann, wenn man es braucht, wird es defekt sein (Murphy) und gerade ein Linux-Anfänger kann so etwas dann nicht mehr "auf die schnelle" gradebiegen. Linux-Profies machen es deshalb (meistens) grundsätzlich nicht ...

Deshalb finde ich den TA Ansatz des "Offline-Image" sehr sinnvoll. Wenn der TA dann zusätzlich den Ordner FHEM aufs Nas kopierst (Siehe Beitrag MadMax), kannst der TA mit "Backup-Karte" + Neuestem FHEM-Backup auf relativ kurze "Ausfallszeiten" kommen. Und das auch für einen Linux Anfänger!

Ich persönlich würde nur das Backup nicht mit FHEM Bordmitteln und tar machen, sondern mit eigenen CRON-Job mit "Backupprogramm" wie dirvish/rsnapshot o.Ä. durchführen, da ich eine Versionierung und Textablage mag. So kann man ohne Probleme in alte Conigs gucken. Und bei einem "verwurschelten" fhem auch nschnell nur dieses zurückspielen. Nur DAS ist auch Geschmacksfrage.

Btw: Wenn man ein obiges Backup eingerichtet hat, könnte man für kurze Ausfallszeiten auch "/etc" Sichern. Dort steht fast 100% der Linuxconfig drin. Nur das geht schon weiter als "für Linux-Anfänger"
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

juergen012

Moin,
zunächst mal Respekt für deine Backup Strategie. Das erfordert Disziplin. Ich würde das so nicht hinbekommen.
Bei mir läuft Fhem in einer VM unter Proxmox. Jede Nacht wird ein Snapshot auf einen Backup Server gemacht. Bei Problemen mit Fhem kann man schnell den Snapshot zrückspielen (Restore). Der Snapshot geht auch auf ein NAS. Ansonsten jede Nacht ein Backup deiner Konfiguration auf das Nas.
Otto hat dazu einen Beitrag erstellt:
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html

Beste Grüße
Jürgen K.
Fhem unter Proxmox