statefile-Backup unter anderem Namen speichern

Begonnen von bismosa, 30 Oktober 2021, 10:03:50

Vorheriges Thema - Nächstes Thema

bismosa

Hallo!

Ich hatte gestern den seltenen Fall, dass ich mir viele Werte (laufende Logdaten) zerschossen habe.
Ich hatte, um meine Performanceprobleme zu finden, diverse (viele) Geräte gelöscht und mit einem Shutdown/Restart alles wiederhergestellt.

Beim Shutdown wurde das Statefile neu geschrieben und alle gelöschten Devices haben ihre readings verloren. Schade. Ich hätte aber vor einem solchen Eingriff auch ein Backup machen sollen.
Ich konnte das meiste aus meinem nächtlichen Backup wiederherstellen. Fand ich aber nicht so prickelnd...da muss ich wieder viel händisch korrigieren (Zählerstände etc.)

Das Statefile sollte man ja nicht selbst schreiben. In diesem Fall bin ich aber glücklich, dass es bei mir regelmäßig (1x pro Stunde) geschrieben wird und ich aus meiner nächtlichen Sicherung dies Wiederherstellen konnte.
Bei uns kommt es auch leider immer mal wieder zu nem Stromausfall so das mir wichtig ist, das statefile gelegentlich zu schreiben.

Meine Idee ist nun, dass man das Statefile regelmäßig unter einem anderen Namen abspeichern könnte.
Vielleicht könnte das writestatefile() in der fhem.pl so angepasst werden, dass man optional einen Dateinamen mit angibt.
Dann könnte man sich über die myUtils einen eigenen State(Log)Rotate bauen, um ein paar Backups der Werte aufzubewahren. Im Falle eines Falles kann sich der (versierte) Nutzer dann selbst aussuchen ob die Werte oder ggf. noch laufende Timer wichtiger sind.

Ich habe in meine myUtils das mal aus der fhem.pl übernommen und leicht geändert. Wenn sich am Code jedoch mal etwas ändert...ist dies keine schöne Variante. Dann kommt da ggf. nur murks bei raus.

Wie seht ihr das?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

rudolfkoenig

Ich kann zwar WriteStateFile mit einem optionalen Parameter erweitern, das waere aber eine halbherzige Loesung.
configDB waere damit raus, der Benutzer muesste logrotate selbst implementieren, und die Konfiguration waere auch nicht gesichert.

Ist der Aufruf von save keine Option?
Vor der Speicherung wird die alte Konfiguration+Statefile im restoredir gesichert, und logrotate ist auch geloest.

bismosa

Hallo!

Für mich ist save leider keine Option, wenn automatisch getriggert.
Wenn ich gerade am testen bin o.ä. möchte ich mir die Möglichkeit nicht verbauen mit einem "shutdown restart" die bisherige Config wiederherzustellen.
Lasse ich stündlich Speichern, bin ich vielleicht noch mittendrin. Und die letzte Version wird im restoreDir ja auch nur 1x/Tag gesichert. Dann ist es schnell schon zu spät.

Auch ein "save [<configfile>]" ist keine Option. Dann könnte ich nicht nachvollziehen ob und welche Änderung es gab (z.B. neu erkannte Sensoren etc.) Das schaue ich mir gerne vor dem Speichern an.
Das "?" verschwindet jedoch auch, wenn unter einem anderen Namen gespeichert wird. Dann vergisst man vor einem "shutdown restart" gerne mal das Speichern.

Ich weiß, dass es schwierig ist, hier eine generelle Lösung die für alle Sinnvoll ist zu schaffen. Ich z.B. möchte mir damit nur meine dauerhaften Readings gegen Ausfall sichern.

Oder wie wäre es mit einem "SaveAs"? Speichert die aktuelle Konfiguration + Statefile in zwei vom User vorgegebene Dateien (in einem angegebenem Verzeichnis).
Das SaveAs triggert dabei aber nicht das event Save. D.h. die normale Konfiguration bleibt unangetastet (und das "?" ggf. bestehen), jeder hat aber die Möglichkeit sich sein Backup (dann sogar gültig mit Konfiguration) selbst zu gestalten.
Dies gleich mit einem "logrotate" umzusetzen halte ich für schwierig. Wer braucht das außer mir?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

rudolfkoenig

ZitatOder wie wäre es mit einem "SaveAs"?
Bevor hier noch weitere, noch kompliziertere Vorschlaege kommen, habe ich WriteStateFile ein Parameter spendiert.
Die eine zusaetzliche Zeile Code sollte niemanden wirklich stoeren.

bismosa

Hallo!

Sorry für den komplizierten Vorschlag und DANKE für die schnelle Umsetzung!
Für mich passt das perfekt  :)

Für mitlesende...ich habe das für mich so in der myUtils gelöst:

sub backupStatefile() {
#Das statefile (fhem.save) in einem anderen Ordner mit Archiv speichern
#Im Verzeichnis vorher (leere) Dateien in gewünschter Anzahl anlegen
#Die älteste Datei wird überschrieben
my ($dir) = '/opt/fhem/restoreDir/Statefiles';
    my $oldest;
    my $oldest_time;
    my $file_spec = File::Spec->catfile($dir, '*.backup');
    foreach (glob $file_spec) {
      my $time = (stat $_)->mtime;
#Log 1, "$_ $time";
      if (!$oldest_time || $time < $oldest_time) {
         $oldest      = $_;
         $oldest_time = $time;
      }
    }
if (not defined $oldest) {
return;
}
WriteStatefile($oldest);
}

Vorher das Verzeichnis mit ein paar Dateien (mit der Endung .backup) anlegen. Die älteste Datei wird beim Aufrufen der Funktion überschrieben.
So habe ich ein Archiv und kann bei Bedarf manuell ein Statefile wiederherstellen. In der Hoffnung, dass ich dies nie benötige.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

betateilchen

Zitat von: rudolfkoenig am 30 Oktober 2021, 14:14:03
Ich kann zwar WriteStateFile mit einem optionalen Parameter erweitern, das waere aber eine halbherzige Loesung.
configDB waere damit raus,

Zitat von: rudolfkoenig am 30 Oktober 2021, 14:58:52
Bevor hier noch weitere, noch kompliziertere Vorschlaege kommen, habe ich WriteStateFile ein Parameter spendiert.

Rudi, das ist doch absioluter Mist!

War nicht unser Bestreben immer, das Verhalten in solchen zentralen FHEM-Funktionen in fhem.cfg und configDB immer synchron und transparant zu halten? Warum machst Du das jetzt plötzlich "kaputt" - und das nur, weil ein einziger User einen Wunsch geäußert hat? Daß Du das kraft Deiner Wassersuppe natürlich tun KANNST, ist klar, dass Du sowas aber wirklich tust, finde ich völlig inakzeptabel.

Wir hätten uns doch zumindest abstimmen können, damit wir eine Lösung implementieren, die in beiden Welten funktioniert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatWir hätten uns doch zumindest abstimmen können, damit wir eine Lösung implementieren, die in beiden Welten funktioniert.
Koennte man das noch nachholen?

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#8
Wenn das mit dem Wünschen hier so einfach geht, dann wünsche ich mir jetzt eine neue Funktion in fhem.pl die "ReadStatefile()" heißt und einen optionalen Parameter für einen eindeutigen Dateinamen hat.

Irgendwie muss eine gesicherte StateFile-Version, die nicht die aktuelleste ist, auch wieder verwendet und in FHEM eingelesen werden können.
Der Dateibenutzer kopiert sich das auf Betriebssystemebene einfach um. In der configDB geht das logischerweise nicht.

Da müssen schon ein paar grundlegende Dinge betrachtet werden, um ein funktionierendes Konzept für eine "Versionierung" des StateFile umzusetzen.
Genau diese Komplexität ist übrigens der Grund dafür, warum das StateFile in der configDB bisher nicht versioniert wurde.


--
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

bismosa

Hallo!

Oh. da habe ich hier ja was angerichtet. Entschuldigung!

Das writestatefile ist ja eigentlich keine "user"-Funktion. Und sollte ja auch eigentlich nicht vom User verwendet werden.

Durch die gelegentlichen Stromausfälle (könnte man mit einer USV Abhilfe schaffen) war ich mehr oder weniger dazu gezwungen, da ich kein automatisches Speichern der Konfiguration möchte.
Bisher war dies in meiner Installation immer problemlos. Sieht bestimmt anders aus, wenn man auch diverse Alarmfunktionen etc. umgesetzt hat. Da kann dies zu mehr Problemen führen!

Ich kenne die ConfigDB bisher noch nicht. Das kam bisher noch nicht in Frage bei mir. Ich mag das einfache Handling mit den Textdateien. Wäre hier bei einem unerwarteten restart dann nicht eh alles noch in der Datenbank vorhanden? Somit würde das Problem hier ja nicht bestehen?

Durch die neue Möglichkeit kann ich das statefile backuppen ohne in das laufende System einzugreifen. Mit dem Nachteil, dass ich das Backup im Fall der Fälle manuell einspielen muss.
Da würde dann vermutlich nur eine Art "Autobackup ohne save" helfen? Oder ein "save <configfile>" ohne global save zu triggern?

Ich merke schon, das dies Thema schwieriger ist als zunächst angenommen. Letztendlich könnte ich (für meinen Fall) auch weiterhin mit dem writestatefile() helfen und diese Datei selbst archivieren. Kommt dann ja aufs gleiche raus. Auch wenn dies nicht der offizielle Weg ist.
Meinetwegen kann die Änderung dann auch wieder entfallen. Es sollte hier kein "wünsch dir was" werden.  :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

betateilchen

Zitat von: bismosa am 30 Oktober 2021, 20:32:14
Meinetwegen kann die Änderung dann auch wieder entfallen. Es sollte hier kein "wünsch dir was" werden.  :)

Man kann über diese Änderung in Form eines feature requests durchaus nachdenken und ich bin ja nicht grundsätzlich dagegen, ein solches Feature umzusetzen. Aber mit solchen Schnellschüssen wie heute passiert, geht das eben nicht.

Mein Vorschlag wäre, die heutige Änderung zurückzunehmen, bis ich parallel ein funktionierendes Konzept für die configDB umgestzt habe, und dann die Änderung zeitgleich bereitzustellen.

Vor dem Release von 6.1 wird das aber bei mir nichts mehr werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatMein Vorschlag wäre, die heutige Änderung zurückzunehmen, bis ich parallel ein funktionierendes Konzept für die configDB umgestzt habe, und dann die Änderung zeitgleich bereitzustellen.
Kann ich machen, aber siehst Du das wirklich als notwendig an?

Fuer Benutzer mit configDB aendert sich durch die Aendurung nichts, und bismosa haette eine Loesung. Falls jemand mit configDB die Funktionalitaet auch haben will, muss halt warten. Sehr verbreitet scheint das Problem ja nicht zu sein, und die Funktion selbst ist auch keine offizielle Benutzerschnittstelle.

betateilchen

Zitat von: rudolfkoenig am 30 Oktober 2021, 20:57:22
Fuer Benutzer mit configDB aendert sich durch die Aendurung nichts,

Doch. Es wird eine Funktionalität bezüglich des Speicherns von Konfigurationsteilen geschaffen, die configDB-Nutzer noch nicht einsetzen können.

Zitat von: rudolfkoenig am 30 Oktober 2021, 20:57:22
Sehr verbreitet scheint das Problem ja nicht zu sein, und die Funktion selbst ist auch keine offizielle Benutzerschnittstelle.

Eben deshalb gibt es m.E. keine Notwendigkeit für so eine einseitige Hauruck-Aktion.

Zitat von: rudolfkoenig am 30 Oktober 2021, 20:57:22
bismosa haette eine Loesung.

Wenn man an einer so grundlegenden Stelle etwas ändert, sollte man das nicht im Rahmen eines "Einzelschickals" betrachten.

Du hattest ja selbst billigend in Kauf genommen, dass alle configDB-Nutzer von dieser Änderung ausgeschlossen werden

Zitat von: rudolfkoenig am 30 Oktober 2021, 14:14:03
configDB waere damit raus,

und diese Denkweise empfinde ich als das eigentliche Problem, das mich gerade massiv enttäuscht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig


bismosa

Hallo!
Zitat von: rudolfkoenig am 30 Oktober 2021, 21:23:38
Ich habe die Erweiterung entfernt.
Danke. Für mich ist das völlig ok. Sorry für die Umstände!

Dann würde ich meinen "Feature Request" nochmal ändern:

Eine offizielle (bzw. automatische) Möglichkeit schaffen, das Statefile regelmäßig zu speichern.
(Damit bei einem Absturz/Ausfall etc. nicht ein zu alter Stand geladen wird.)
Optimalerweise mit einem Archiv z.B. in der backupdir.

Vielleicht ist dies ja etwas für eine künftige Version.
Ich habe häufiger im Forum von Problemen diesbezüglich gelesen. (Hier wird dann auch häufiger der Tipp mit dem writestatefile() weitergegeben.)
Ich bin bestimmt nicht der einzige?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...