"Neues" Verhalten save und restoredirs

[Otto123]

Hallo,

mit ist gerade aufgefallen: Seit November 2017 (wenn ich richtig liege) sichert save ja die fhem.cfg nach restoreDir, pro Tag ein Verzeichnis und dort nur die letzte Version. Per default 3 Verzeichnisse.

Früher habe ich die Hauptinstanz, sagen wir mal jeden Monat mit update versorgt und hatte damit 3 Monate zurück alte Stände auf die man einfach zurück konnte, auch wenn man Fehler erst nach ein paar Tagen festgestellt hat.

Jetzt drücke ich einmal am Tag save weil ich die geänderte Konfiguration sichern will und meine Chance auf restore eines älteren Versionsstandes von FHEM ist nach 3 Tagen dahin. 
 
Ich kann jetzt restoredirs hochsetzen ...

Wäre es nicht besser, bei save nur die fhem.cfg ins letzte restoredir (was generell nur bei update erzeugt wird) mit einem Zeitstempel Zusatz zu sichern?
Damit hätte man alle Versionen der fhem.cfg und die Module vorm letzten update.

Ob man die Versionierung der fhem.cfg beim restore Befehl berücksichtigen muss bezweifle ich.

Auf alle Fälle ist der default Wert 3 für restoredirs für mich fragwürdig.

Gruß Otto

[CQuadrat]

Ich schließe mich dieser Meinung und dem Lösungsvorschlag von Otto an!

Auch mir verhageln regelmäßige Saves und die damit verbundene Versionierung der fhem.cfg die Langzeitarchivierung der Module bzw. des gesamten Fhem-Versionsstandes.

[dev0]

Ich fände es auch sinnvoll, dass die fhem.cfg's getrennt gesichert werden und die "restore" Verzeichnisse ausschließlich vom Backup verwendet würden. Mir ist es aber nicht so wichtig, dass ich mich einarbeite und einen Patch schreiben möchte...

[rudolfkoenig]

Das Problem an sich ist mir schon laenger bekannt, ich habe aber lange gezeogert, weil ich keine einfache Loesung gefunden habe.

Mein Problem mit dem Vorschlag von Otto123 ist, dass es nicht beschreibt, wie die Kopien zu loeschen sind (ich will nicht unendlich viele aufheben, und ich wette dass es Benutzer gibt, die minuetlich save aufrufen), und fuers Restaurieren mit restore muesste man auch was Neues bauen. Weiterhin ist es nicht intuitiv nach einem aktuellen fhem.cfg in einem alten restoreDir Verzeichnis zu suchen. Btw.: save speichert nicht nur fhem.cfg, sondern auch fhem.save.

Ich habe jetzt Folgendes eingebaut/geaendert:
- update speichert ersetzte Dateien unter restoreDir/update/YYYY-MM-DD
- save speichert die Konfiguration unter restoreDir/save/YYYY-MM-DD
- die Anzahl der Datums-Verzeichnisse haengt wie bisher von "attr global restoreDirs" ab, wird aber in update und save separat gezaehlt.
- die alten Verzeichnisse (restoreDir/YYYY-MM-DD) bleiben, sie koennen manuell geloescht werden
- restore restauriert nur dann, falls das Argument YYYY-MM-DD enthaelt, sonst wir der Inhalt angezeigt.

[dev0]

Klingt gut. Danke.

[Otto123]

Guten Morgen,

ja klingt gut, danke auch von mir.
Ich wollte nicht so "aufwendig" denken und vorschlagen.

Ich für meinen Teil sehe ja meine fhem.cfg in erster Linie in meiner Verantwortung. Ich überlege ja bei jeder Änderung, gehört das gespeichert oder nicht.

Mit dem jetzigen Ansatz ist der alte Zustand für die update Situation wiederhergestellt und die fhem.cfg und fhem.save wird unabhängig täglich bei save gesichert. Allerdings nur der letzte Stand des Tages.

Was ich damit sagen will: Wir rücken damit die Konfiguration etwas aus dem notwendigen Aufmerksamkeitsfocus des Anwenders allerdings ist es keine perfekte Versionierung.

Gruß Otto

[Pnemenz]

Ich weiß nicht, ob es etwas mit dem heutigen Update zu tun hat, aber wenn ich über ein Script folgendes Aufrufe:

Code: [Auswählen]

/usr/bin/perl /opt/fhem/fhem.pl 7072 update check
bekomme ich folgeden Antwort:

Code: [Auswählen]

Prototype mismatch: sub main::restoreDir_init (;$) vs ($) at /opt/fhem/fhem.pl line 5441.
nothing to do...
Bis heute Früh ging das ohne Prototype mismach..
LG
Peter

[rudolfkoenig]

Bis heute Früh ging das ohne Prototype mismach..

Stimmt, und ab einem update morgen sollte das wieder gefixt sein.
Ist mir vorhin selbst aufgefallen.

[Tueftler1983]

hallo habe ein Problem bei mir wird kein Update mehr ausgeführt.

im Log habe ich jetzt das stehen

Code: [Auswählen]

2018.03.18 23:17:15 1:
2018.03.18 23:17:15 1: fhem
Undefined subroutine &main::restoreDir_init called at ./FHEM/98_update.pm line 274.
Habe schon einen Beitrag dazu:
https://forum.fhem.de/index.php/topic,85945.0.html

Bitte um Hilfe

[Tueftler1983]

Problem gelöst, habe von github die neue fhem.pl runtergeladen und auf den pi geschoben. danach lief ein update normal durch!

[Otto123]

Moin,

jetzt habe ich mit meiner Anregung auch noch ne Reihe von Problemen und Aufwand los getreten - peinlich. 

Tschuldigung
Otto

[frank]

otto, das hatte nichts mit deiner sinnvollen anregung zu tun.

[nils_]

Problem gelöst, habe von github die neue fhem.pl runtergeladen und auf den pi geschoben. danach lief ein update normal durch!

github ??

[rudolfkoenig]

Problem gelöst, habe von github die neue fhem.pl runtergeladen und auf den pi geschoben. danach lief ein update normal durch!

1. keine Ahnung wer wenn github aktualisiert, offiziell werden Code-Aenderungen in subversion auf svn.fhem.de eingecheckt, und das wird taeglich vor 8:00 fuer das FHEM-update bereitgestellt
2. wenn nach einem update Probleme gibt, dann sollte man im restoreDir die alte Version suchen und zurueckkopieren. Wenn FHEM noch einigermassen laeuft, dann mit dem restore FHEM Befehl.
3. das beschriebene Problem kilngt sehr nach selektiven update einzelner Dateien, das ist weder getestet, noch unterstuetzt.

[Tueftler1983]

Okay war auch nicht die Lösung.. denn nach dem Update was ohne probleme durch lief geht garnix mehr. fhem ist nicht mehr erreichbar.
auch ein rückspielen der alten dateien hilft nicht

lade brade ein altes Backup vom dezember hoch mit einer blanken fhem.cfg.. das klappt und läuft.

Jetzt ein Update und danach will ich meine cfg wieder hochladen