Webfrontend wird nach "configdb Backup" nicht mehr dargestellt

[Rince]

Wäre ich ein Moderator, würde ich euch beiden ja den dringenden Tipp geben, mal ein Bierchen miteinander zu trinken.
So lese ich halt mit, wie zwei ausgesorochen fähige Köpfe ihre Energie und Zeit damit verschwenden, einen reichlich unsinnigen Diskurs zu führen.
Rudi fühlt sich angegriffen, Betateilchen unverstanden. Merkt ihr eigentlich, dass euch das zum Einen öfter passiert und zum Anderen nicht weiter bringt?

Sorry für das OT.

[svenson08]

Das Thema Backup halte ich auch in fhem für wichtig. Meine mir unterstellten Backupadmins würden hier eher eine Lösung Suchen bei der das Backup möglich umfangreich und vom Inhalt verlässlich ist. Lieber zuviel als zuwenig im Backup haben als später fest zu stellen das was wichtiges fehlt.
Wohl daher versteh ich die gesamte Diskussion nicht. In meinem Verantwortungsbereich gibt es zum Glück einen klar definierten zweck eines Backups.

Für mich ist wichtig das ich fhem neu aufsetzen kann und mit dem Backup wieder in den Zustand versetzen kann in dem es zu dem Zeitpunkt war. Das ist auch ohne configdb nicht gegeben, was ich vor Wochen merken musste - das waren bei mir z.b. eigene .js und .svg Dateien.
Das ist keine Kritik an Rudi, es ist im Moment halt so.

Das ist bisher auch ein Grund die configdb nicht produktiv zu nutzen. Und ich möchte einen Befehl absetzen um ein Backup zu bekommen und nicht noch mich separat um die DB zu kümmern - auch wenn das anders gesehen wird. Aber das Leben ist kein Wunschkonzert und nicht alle sehen das wie ich, und das ist auch gut so.

[rudolfkoenig]

@betateilchen: wenn ich das nicht verstanden habe, bitte klaer mich auf. Ich habe folgendes verstanden: bei configDB sind  alle FHEM-Konfigurationen in der Datenbank, und nicht im Filesystem. Das backup Kommando fasst aber nur Dateien aus dem Filesystem an -> ergo sind in dem erstellten Backupdatei keine Konfigurationsdaten. Ein configDB Benutzer muss also unbedingt auch die Datenbank sichern, damit beim Restaurieren alles vorhanden ist. Irgendwie habe ich die Befuerchtung, dass du davon ausgehst, dass die Datenbank nicht restauriert werden muss, da sie auf einem anderen Rechner ist, oder es eh anderweitig gesichert wird.

@Klaus: mit deinem Vorschlag (Warnung an dem Benutzer) kann ich leben, aber wir warten erstmal ab, was der Stand ist, ich will ja keine Geruechte ins Welt setzen, solche gibt es im FHEM Umfeld schon genug.

@svenson08: ich habe das Modul auch nur geerbt. Wenn sich jemand dafuer interessiert, kann ich es gerne abgeben.
Ich selbst verwende es nicht, da ich den Rechner komplett sichere, und das nicht aus FHEM-heraus.

[betateilchen]

Das ist bisher auch ein Grund die configdb nicht produktiv zu nutzen. Und ich möchte einen Befehl absetzen um ein Backup zu bekommen und nicht noch mich separat um die DB zu kümmern

Exakt das wäre längst gegeben, wenn Rudi einfach nur die vor vielen Wochen vorgeschlagene Änderung in das backup-Modul eingebaut hätte, anstatt sich darüber gedanken zu machen, ob ER das backup für sinnvoll hält oder nicht.

Der ganz normale Backup-Prozess hätte dann dafür gesorgt, dass die gesamte Konfiguration EINSCHLIESSLICH der Datenbank mitgesichert wird, unter einer einzigen vom Benutzer zu erfüllenden Voraussetzung: Die Datenbank müsste dazu im fhem Verzeichnis liegen.

Ich dachte ein Backup der dB hat alle configs inne. Daher dachte ich bisher das zu dem bisherigen Backup "nur" das Backup der dB angehängt werden muss.

Das war mein ursprünglicher Plan - dazu hätte es der bereits erwähnten winzigen Änderung bedürft, im Backup Modul eine Fehlermeldung abzufangen, die nur auftritt, wenn configDB benutzt wird.

Wäre ich ein Moderator, würde ich euch beiden ja den dringenden Tipp geben, mal ein Bierchen miteinander zu trinken.

Ich hatte auf dem Treffen in Karlsruhe schon eine weitere Klärung der Backup-Frage vorgeschlagen, konnte damals aber leider kein echtes Interesse, eine Klärung herbeiführen zu wollen, erkennen.

Und ganz nebenbei fände ich es noch toll, wenn nach dem Backup der FHEM Screen wieder erscheint 

Auch das wäre nebenbei mit gelöst.

[betateilchen]

Ein configDB Benutzer muss also unbedingt auch die Datenbank sichern, damit beim Restaurieren alles vorhanden ist.

Ein configDB Benutzer muss nur dann die Datenbank eigenverantwortlich sichern, wenn sie sich nicht im fhem Verzeichnispfad befindet.
Genau so ist das aber auch mit allen anderen von fhem benutzten Dateien, die NICHT im fhem-Verzeichnis liegen.

Ich verstehe bis heute nicht, warum Du das Ganze plötzlich davon abhänging machst, ob ein Benutzer, der configDB nutzt, irgendwelche Daten ausserhalb von fhem ablegt oder ob das ein Benutzer, der fhem.cfg nutzt, tut. Für mich ist diese von Dir praktizierte Verweigerungshaltung "configDB Nutzer dürfen das Backup-Modul nicht benutzen" nach wie vor rein willkürlich und unerfindlich.

[svenson08]

@svenson08: ich habe das Modul auch nur geerbt. Wenn sich jemand dafuer interessiert, kann ich es gerne abgeben.
Ich selbst verwende es nicht, da ich den Rechner komplett sichere, und das nicht aus FHEM-heraus.

Das weis ich, darum will ich auch nicht das du als Vorwurf siehst. Ich sichere mit dem Backup Befehl und meinen kompletten Pi. Aber ich denk an den Nutzer der das nicht macht und der nicht weis wie es geht. Die Benutzer freundlichere Lösung sollte doch auch das Ziel sein. Und wenn es nur die Fritz box user wären an die man denkt

@betateilchen
Willst du nicht das Modul Übernehmen? Das Know how dazu hast du nach meiner Einschätzung. Ich müsste mich da zuviel einarbeiten, was mir über den Sommer nur schwer gelingen würde. Auch ist mein perl noch nicht so gefestigt....

[betateilchen]

@betateilchen
Willst du nicht das Modul Übernehmen?

An dem Modul sind keinerlei Änderungen nötig, ausser der ursprünglich gewollten Änderung, die das Abfangen einer Fehlermeldung betrifft. Dazu habe ich seinerzeit bereits einen funktionierenden Patch vorgeschlagen.

http://forum.fhem.de/index.php/topic,20117.msg147122.html#msg147122

Anstatt den Patch einzubauen, hat Rudi seinerzeit sowohl das update- als auch das backup-Modul angefaßt und geändert, nur um configDB Nutzern die Backupmöglichkeit grundsätzlich und vollständig verweigern zu können.

Selbst wenn ich das backup-Modul übernehmen würde (wozu es keine Notwendigkeit gibt) könnte ich die gewünschte Änderung damit nicht mehr vornehmen, weil configDB Nutzer aktuell an zwei Stellen grundlos benachteiligt werden und die Sperre auch in update.pm wieder zurückgebaut werden muss.

Die einfachste und für alle am transparentesten Lösung wäre einfach die, dass Rudi den schon im März von mir vorgeschlagenen Patch in die 98_backup.pm übernimmt und auch die benachteiligende Änderung in der 98_update.pm wieder ausbaut.

[Rince]

Anstatt den Patch einzubauen, hat Rudi seinerzeit sowohl das update- als auch das backup-Modul angefaßt und geändert, nur um configDB Nutzern die Backupmöglichkeit grundsätzlich und vollständig verweigern zu können.

Ich würde an Rudis Stelle hier auch auf stur schalten. Nicht weil es technisch notwendig wäre, sondern weil ich mich massiv angegriffen fühlen würde.

Ist ne blöde Situation.

Letztlich solltest du, Betateilchen, Rudi eine Brücke bauen, so dass Rudi den Patch einbauen kann, ohne dabei sein Gesicht zu verlieren.

Vielleicht würde ein "entschuldige Rudi, ich hab mich damals schlecht ausgedrückt" ausreichen? Aber das ist Rudis Sache.

[rudolfkoenig]

Weder braucht betateilchen sich zu entschuldigen, noch habe ich ein Problem damit "mein Gesicht zu verlieren", bzw. meine Meinung zu aendern.

Wenn ich es recht verstanden habe, FHEM macht vielleicht ein Backup der Datenbankdatei, aber sicher ist das nicht: Falls der Anwender kein sqlite verwendet, oder per config die sqlite-Datei nicht in modpath liegt, dann wird die Konfiguration samt DB nicht gesichert.

Ich haette kein Problem auch bei configDB das Backup durchzufuehren, wenn der Benutzer per Warnhinweis (wie vom Klaus vorgeschlagen) gewarnt wird. Den Hinweis koennen wir unterdruecken, wenn configDB per Funktion verraet, dass die Datei im Backup ist.

[Klaus Rubik]

Hallo,

also den Vorschlag von Rudi finde ich doch als gangbaren Weg, ich denke nun ist es nach der ausführlichen Diskussion Zeit sich die Hand zu reichen und den Vorschlag umzusetzen.

Ohne jetzt zusätzliches Öl ins Feuer giessen zu wollen, aber kann mir jemand erklären, welchen Nachteil configDB User bei update haben ?

Viele Grüße und gute Nacht

Klaus

[Blackcat]

Was ist eigentlich der Vorteil der Datenbank? Ich sicher immer einfach meine komplette Pi sd Karte nach einer Woche

[betateilchen]

Wenn ich es recht verstanden habe,
...
Falls der Anwender kein sqlite verwendet, oder per config die sqlite-Datei nicht in modpath liegt, dann wird die Konfiguration samt DB nicht gesichert.

Du hast immer noch nicht verstanden, dass diese von Dir hier seit Wochen vehement breitgetretene Behauptung schlichtweg FALSCH ist. Es kommt nicht darauf an, welches Datenbanksystem verwendet wird, sondern wo die Datenbank abgelegt ist. Und damit verhält sich die Datenbank exakt identisch zu allen anderen von fhem verwendeten Dateien, die sich nicht im direkten fhem-Pfad, der von 98_backup gesichert wird, befinden.

Ich verstehe nach wie vor nicht, warum Du diese völlig sinnlose Differenzung ausschliesslich bei der configDB einführen musstest. Wenn ich beispielsweise RSS Layouts ausserhalb von fhem speichere, werden sie von 98_backup.pm auch nicht mit gesichert.

Die Sache mit dem Hinweis können wir gerne einbauen. Aber ich würde dabei im Falle der Nutzung von configDB den Anwender generell immer darauf hinweisen, dass er für die Datensicherung seiner Konfigurationsdatenbank selbst verantwortlich ist. 98_backup.pm kann nicht ohne weiteres feststellen, ob die Sicherung eine Datenbank enthält oder nicht, das das gesamte fhem zur Laufzeit überhaupt nicht weiss (und auch gar nicht wissen muss), wo die Datenbank tatsächlich liegt.

[betateilchen]

Was ist eigentlich der Vorteil der Datenbank? Ich sicher immer einfach meine komplette Pi sd Karte nach einer Woche

Das ist ein völlig anderes Thema und gehört hier nicht her. Du kannst das aber bereits mehrfach erklärt hier im Forum nachlesen.

[Klaus Rubik]

Du hast immer noch nicht verstanden, dass diese von Dir hier seit Wochen vehement breitgetretene Behauptung schlichtweg FALSCH ist. Es kommt nicht darauf an, welches Datenbanksystem verwendet wird, sondern wo die Datenbank abgelegt ist. Und damit verhält sich die Datenbank exakt identisch zu allen anderen von fhem verwendeten Dateien, die sich nicht im direkten fhem-Pfad, der von 98_backup gesichert wird, befinden.

Hallo Betateilchen,

so ganz bin ich da nicht bei Dir, einfach nur die DB Files zu sichern mag bei SQlite ausreichen, bei "vernünftigen" Datenbank-Systemen wie z. B. Oracle musst du die Datenbank zumindest in einen konsistenten "Backup-Mode" versetzten, damit alle Daten auch aus den DB Caches in den Files liegen. Daher sollte die DB immer mit DB Spezifischen Backups und wenn es nur ein SQL Export ist gesichert werden.

Viele Grüße

Klaus

[betateilchen]

Daher sollte die DB immer mit DB Spezifischen Backups und wenn es nur ein SQL Export ist gesichert werden.

Das ist völlig richtig. Aber das ist eine Aufgabe, die ich in configDB für mehrere denkbare Datenbanksysteme weder umsetzen kann noch will. Deshalb liegt die Verantwortung der Datenbanksicherung beim Anwender. Es steht ihm völlig frei, z.B. über einen Cronjob regelmäßig einen Datenbank-Dump zu erzeugen, der im fhem-Pfad abgelegt und damit von 98_backup mitgesichert wird.

Allerdings ist das Problem im Falle von configDB nicht so dramatisch wie beispielsweise bei DbLog (wo es eine Diskussion über Backupmöglichkeiten innerhalb von fhem noch nie gab!) denn der grundlegende Unterschied ist, dass die configDB nicht permanent geöffnet ist, sondern nur geöffnet wird, wenn man wirklich etwas daraus lesen oder hinschreiben möchte, danach wird die Verbindung sofort wieder abgebaut. Insofern wird auch eine low-level Sicherung auf Datenbankebene in den allermeisten Fällen funktionieren, denn bei einer geschlossenen Datenbank gibt es keine Daten mehr im Cache, die noch nicht in die Datenbank geschrieben sind.

SQLite bietet in diesem Zusammenhang den Vorteil, dass dort quasi alle Ebenen verschwunden sind und wir uns wirklich nur auf Dateiebene bewegen. Es bedeutet aber nicht, dass SQLite die einzige Möglichkeit bietet, eine Sicherung aus fhem heraus zu ermöglichen. Deshalb fand ich auch den von Rudi schon vor längerem formulierten Vorschlag, ich solle mich bei configDB auf SQLite als einzige Möglichkeit beschränken, dann würde er die Sicherung per 98_backup wieder ermöglichen, völlig absurd.

Noch ein Vorschlag, um zu zeigen dass ich nicht bockig bin: Du streichst den Support fuer andere Datenbanken in configDB, dann werde ich dein Patch einbauen (vorausgesetzt es ist getestet und funktioniert).