fhem.cfg backup wiederherstellen

[abc2006]

Hallo,

Ich habe sichere meine fhem.cfg bei jedem "save" mit einem doif/notify:

Code Auswählen Erweitern

global:SAVE {
my $now = strftime "%Y%m%d%H%M%S",localtime();
system("cp $attr{global}{configfile} ./backup-cfg/fhem.cfg.$now");
system("cp $attr{global}{statefile} ./backup-cfg/fhem.state.$now");
}

Dadurch besitze ich ein Verzeichnis mit vielen cfg-, und state-files (Hab ich vor langen Jahren mal hier im Forum gefunden).

Nun hatte ich bereits mehrfach das Gefühl, dass das wiederherstellen der alten fhem.cfg nicht richtig funktioniert, d.h. das System dadurch nicht auf einem alten Stand landet.

Nun habe ich heute die Situation, dass ich eine Änderung an FHEM vorgenommen habe (ich habe ein Device kopiert) und daraufhin in einem Modul einige Änderungen vorgenommen habe, ohne vorher auf "save" zu klicken. Fhem ist abgestürzt (wegen einem von mir verursachten Fehler im Modul) und ich musste den Raspberry neu starten.
Nach dem neustart waren alle Änderungen weg, die ich seit dem letzten save durchgeführt hatte.

Also habe ich die alte fhem.cfg, gesichert wenige Minuten vorher durch mein notify, an die Stelle der neuen fhem.cfg kopiert:

Code Auswählen Erweitern


service fhem stop
cp /opt/fhem/backup-cfg/fhem.cfg.20191021093626 /opt/fhem/fhem.cfg
service fhem start


Doch seit diesem vorgehen sind die devices, die in der fhem.cfg definiert sind, nicht identisch mit denen, die im Fhemweb angezeigt werden.
d.h. im Fhemweb fehlt eines.

Dann hatte ich vermutet, ob es an identischen ID's liegen könne, aber auch diese sind unterschiedlich.

Dann habe ich überlegt, ob es an der falschen fhem.save liegen kann - aber auch hier hat ein "restore" auf die vorherige Version nichts gebracht.

Mein "Datenverlust" ist jetzt nicht schlimm, ich kopiere die Zeilen aus der alten cfg und füge sie neu ein, oder lege gleich das ganze Gerät neu an.
Aber: Kann mir jemand nen Tipp geben, was ich falsch mache?
Weil: Wenn ich die Dateien aus dem Backup *nicht* wiederherstellen kann (bzw. sie dann nicht verwendet werden), muss ich mir Gedanken um ein neues Konzept machen ...

Danke für eure Hilfe, wenn Informationen fehlen, liefere ich die gerne noch nach.
PS: das "restore"-Script funktioniert nach meinem Verständnis (und meinen tests) nur für Backups, die durch ein "update" erstellt wurden. Das hilft mir in meinem konkreten Fall leider wenig.

Grüße,
Stephan 

[rudolfkoenig]

Was Vergleichbares zu deinem notify wird seit laengerem automatisch gemacht, nach restoreDir/save. Anzahl der gesicherten Versionen ist 3, kann mit "attr global restoreDirs" geaendert werden.
Beim Restarurieren muss man auch noch die state File zurueckkopieren, sonst fehlen alle eimaligen at's und alle Readings.
Weiterhin fehlen abgespeicherte Passworter bei bestimmten Modulen, und dynamisch erstellte/modifizierte .gplot Files.
Vermutlich auch weitere Daten, ich kenne nicht alle Module auswendig.

[abc2006]

Hi Rudi, danke für deine schnelle Antwort.

Was Vergleichbares zu deinem notify wird seit laengerem automatisch gemacht, nach restoreDir/save. Anzahl der gesicherten Versionen ist 3, kann mit "attr global restoreDirs" geaendert werden.

Schau ich mir auf jeden Fall an.

Beim Restarurieren muss man auch noch die state File zurueckkopieren, sonst fehlen alle eimaligen at's und alle Readings.
Weiterhin fehlen abgespeicherte Passworter bei bestimmten Modulen, und dynamisch erstellte/modifizierte .gplot Files.
Vermutlich auch weitere Daten, ich kenne nicht alle Module auswendig.

Okay, daraus entnehme ich aber, dass selbst wenn ich nur die fhem.cfg wiederherstelle, keine Devices fehlen dürften, so wie es anscheinend bei mir der Fall ist?

Grüße,
Stephan

[abc2006]

Das restoreDir ist eine schöne Funktion, und ich werde es in Zukunft zusätzlich verwenden.

Es kann meine eigene Funktion aber leider nicht ablösen, da pro Tag lediglich der letzte Stand gesichert wird (d.h. bei restoreDirs 10 habe ich von *heute* trotzdem lediglich *einen* Stand), was den gewünschten Zweck bei größeren config-Änderungen (so wie heute) nicht ausreichend erfüllt.

Danke trotzdem für den guten Hinweis
Grüße,
Stephan

[PatrickR]

uniqueId nicht vergessen. Ein regelmäßiger Quell der Freude.


Gesendet von iPhone mit Tapatalk Pro

[Otto123]

Zu dem was Rudi gesagt hat noch ein praktisches Beispiel:

Code Auswählen Erweitern

restore list savezeigt

Code Auswählen Erweitern

2019-10-21

Code Auswählen Erweitern

restore list save/2019-10-21zeigt den Inhalt der gesichert wurde (in log liegt noch die Datei fhem.save)

Code Auswählen Erweitern

restore list save/2019-10-21/log

Ein

Code Auswählen Erweitern

restore save/2019-10-21 würde diesen Zustand wieder herstellen.

Nachteil gegenüber Deiner Methode: nur eine Version(die letzte) pro Tag!

Was allerdings bei Dir jetzt wirklich bei deinem Restore passiert ist kann ich nicht sagen - ich schaue nie in die fhem.cfg
Du musst aber beachten, das beim Laden der fhem.cfg meines Wissens fehlerhafte Definitionen übergangen werden. Das kann dazu führen, dass in der aktiven Konfig nicht alles steht was in der fhem.cfg definiert ist.

Gruß Otto

[abc2006]

uniqueId nicht vergessen. Ein regelmäßiger Quell der Freude.

Da hast du recht, Device kopiert mit copy, ID's sind unterschiedlich.
hab ich grade auch nochmal verifiziert.

[abc2006]

Zu dem was Rudi gesagt hat noch ein praktisches Beispiel:

Hi Otto,
danke für die genaue Anleitung!
Dass nur die letzte Version pro Tag vorgehalten wird, ist mir auch schon aufgefallen und schmälert die Freude etwas

Grüße,
Stephan

[Otto123]

Da war ich jetzt zu langsam mit editieren:
Du musst aber beachten, das beim Laden der fhem.cfg meines Wissens fehlerhafte Definitionen übergangen werden. Das kann dazu führen, dass in der aktiven Konfig nicht alles steht was in der fhem.cfg definiert ist.

[Beta-User]

...dann nutze doch configDB; da sollten die Daten jeder gespeicherten Version auch soweit konsitent sein (ich nutze das feature, alte Versionen zu laden, so gut wie nie, soweit habe ich die Konfiguration noch nie gekillt)...

(Und das ganze klingt irgendwie auch nach cfg-Editieren. Ist (nur dann) ok, wenn man weiß, was man tut .)

[abc2006]

Da war ich jetzt zu langsam mit editieren:
Du musst aber beachten, das beim Laden der fhem.cfg meines Wissens fehlerhafte Definitionen übergangen werden. Das kann dazu führen, dass in der aktiven Konfig nicht alles steht was in der fhem.cfg definiert ist.

Ohne jede Fehlermeldung ?
Nichtmal bei attr global verbose 5?

[Otto123]

Ich hatte das noch nie. Ich kann es nicht sagen, ich weiß bloß um diese "Diskussionen" und ich weiß von Berichten wo nach Fehlern im CUL_HM Modul nach dem Start Geräte nicht mehr da waren (und dann aus der fhem.cfg gelöscht wurden wenn man in dem Zustand wissentlich save gedrückt hat).

[abc2006]

Hi Otto,
das ist ein interessanter Punkt, da es bei mir ja auch um "Probleme nach Modifikationen an einem Modul" geht.
Folgende Fakten:
Bei mir steht autosave auf 0
Ich habe Änderungen am Modul 39_STELLMOTOR vorgenommen, verschwunden ist aber ein PID20-Device...
Das Device steht in der fhem.cfg drin:

Code Auswählen Erweitern


define PID_HV PID20 OW_HV_RLA:temperature Mischer_RLA_HV:position
setuuid PID_HV 5d8abc1b-f33f-5164-5341-03d16944a42ff8fd
attr PID_HV comment positive Werte: mehr Vorlaufwasser/Temperatur muss höher/nach links drehen\
negative Werte: mehr kaltes Wasser/Temperatur soll niedriger/nach rechts drehen
attr PID_HV event-on-change-reading state
attr PID_HV event-on-update-reading actuation,actuationCalc,p_d,p_i,p_p,measured,desired,delta,restarted
attr PID_HV pidActorInterval 1
attr PID_HV pidActorLimitLower 0
attr PID_HV pidActorLimitUpper 90
attr PID_HV pidActorTreshold 0
attr PID_HV pidActorValueDecPlaces 0
attr PID_HV pidCalcInterval 15
attr PID_HV pidFactor_D 10
attr PID_HV pidFactor_I 0.75
attr PID_HV pidFactor_P 5
attr PID_HV room PID
attr PID_HV stateFormat {sprintf("%s, A: %.0f D: %.1f %s",ReadingsVal($name,"state",0),ReadingsVal($name,"actuation",0),ReadingsVal($name,"delta",0),ReadingsTimestamp($name,"actuation",0))}
attr PID_HV userReadings x_PID_OFFSET {ReadingsVal("PID_HV_VL85","actuation","unknown")},\
x_VL_HV {ReadingsVal("OW_HV_VL","temperature",-1)},\
x_VL_RLA {ReadingsVal("OW_HV_RLA","temperature",-1)},\
x_VL_RL {ReadingsVal("OW_HV_RL","temperature",-1)}


wurde aber in FHEMWEB nicht angezeigt.
Unglücklicherweise habe ich es bisher nicht geschafft, den Fehler zu reproduzieren (weshalb ich bisher nicht nachgefragt hatte)

Nachdem ich das Device jetzt wieder angelegt habe, funktioniert alles wieder wie gewünscht (egal ob per Define oder Raw Definition)
Meine Überlegung war, ob ich eine Datei vergessen habe. Das scheint nicht der Fall zu sein.

Nun komme ich nicht mehr weiter...

Danke für eure Unterstützung,
Stephan

[Beta-User]

Solche Effekte können mMn. auftreten, wenn die Reihenfolge der Definitionen nicht stimmt oder Abhängigkeiten nicht aufgelöst werden können (hier scheinbar: das Zieldevice für PID20 verloren gegangen, da dessen Modulcode "kaputt" war).

Eigentlich sollte dazu was im Log stehen, aber was, hängt auch davon ab, was der Modulautor festgelegt hat... Der Modulcode von PID20 sollte dazu Auskunft geben (in der Regel im Define).

Wenn da (vielleicht) Auffälligkeiten festzustellen sind, wäre m.E. der Modulautor anzufragen, ob er was an dem Verhalten ändern will (insbesondere: $init_done abwarten, bevor die Modulinitialisierung fertiggestellt wird bzw. das Modul wieder deaktiviert).

[abc2006]

Hey, danke für diese Idee.
Als interessante Nebeninformation:
Verstehe ich das richtig, dass du sagt, dass die Definition von PID20 erst dann passieren darf, wenn das Zieldevice definiert wurde?
Ich schaue mir mal das Define vom PID20 an und frage ggf mal beim Autor nach. Allerdings hat ausser mir ja anscheinend noch niemand das Problem gehabt.

Grüße,
Stephan