Ich hatte einen Worst-Case Szenario - FHEM Dateien weg. Kein Problem: Gibt ja Backups.
Ist auch alles drin, aber alle Configs, die per Include eingebunden waren (liegen im ./FHEM/*.cfg) haben 0KB! Alle Dateien in Ordnung, nur diese Dateien sind leer.
Im Wiki steht etwas von Expertenmodus: https://wiki.fhem.de/wiki/Include das heißt für mich aber nicht dass keine Backups angelegt werden?!
Alles von Vorne machen. Komplettes System. Nice.
Da merkt man mal wieder dass man saubere Backups haben sollte und auf kein einzelnes Backupsystem vertrauen kann.
Ich habe auf einer zweiten frischen FHEM Installation ausprobiert. Das Problem ist reproduzierbar.
Von Config Dateien, die per Include in ./FHEM/*.cfg liegen wird kein Backup angefertigt. Immer 0KB.
Und mit Backup meine ich attr global backup_before_update 1
das backup unterschiedet nicht und scihert stumpf das fhem verzeichnis... solltest du dir durch falsches editieren der (warum auch immer) includeten cfg's ein rechteproblem eingehandelt haben kann fhem diese cfg's natürlich nicht sichern. die 0 kb deuten zumindest darauf hin das die dateien gefunden wurde, durch backup versucht zu kopieren, aber nicht lesbar waren.
ZitatHinweis: Die Verwendung des Befehls include gehört zum "Expertenmodus".
hier müsste im wiki ehr stehen: Hinweis: Die Verwendung des Befehls include gehört zum "Anfängermodus" da ein fhem experte wüsste, das man die DEF funktion im fhem-web nutzt um anpassungen zu machen und somit die vermeintliche ordnung durch aufteilenm der cfgs völlig sinnfrei ist
Zitat
Da merkt man mal wieder dass man saubere Backups haben sollte und auf kein einzelnes Backupsystem vertrauen kann.
man verlässt sich nie blind auf ein backup. du musst immer mal wieder prüfen ob dein backup i.O. ist und nicht erst wenn du es brauchst. da nutzen dir auch 100 Backupsystem nichts wenn alle defekt sind.
eines reicht völlig wenn es funktioniert
Ich behaupte mal, es liegt am Archiv Programm.
Öffne ich das Archiv mit dem in Ubuntu eingebauten Dateimanager (nautilius) habe ich die .cfg-Dateien doppelt und eine davon ist 0KB.
Entpacke ich die Datei über die Konsole mit tar, dann habe ich die Ordner wunderhübsch im Originalformat mit allen Dateien .
EDIT:
Zitat.... und somit die vermeintliche ordnung durch aufteilenm der cfgs völlig sinnfrei ist
Meine include .cfg Dateien sind ein Relikt aus meinen FHEM Anfangszeiten gewesen - hatte mir schon länger vorgenommen diese zu entfernen. Zufällig hab ich mich gestern Morgen überwunden und alles in die fhem.cfg kopiert und die ganzen includierten .cfg Dateien beseitigt.
Das entscheidende ist die Aussage
Zitat
Und mit Backup meine ich attr global backup_before_update 1
Bevor ein Update gemacht wird werden die jeweiligen Dateien welche ein Update erfahren gesichert. Das sollten in der Regel nur Programmodule sein.
Oder ich habe es falsch verstanden.
Zitat von: chris1284 am 06 März 2017, 08:20:21
ein rechteproblem eingehandelt haben kann fhem diese cfg's natürlich nicht sichern
Nein. Alle Dateien haben die gleichen Rechte im FHEM Ordner. Gleicher User/Gruppe und chmod 644. Überprüft mit frischer FHEM Installation.
Zitat von: chris1284 am 06 März 2017, 08:20:21
die Verwendung des Befehls include gehört zum "Anfängermodus" da ein fhem experte wüsste, das man die DEF funktion im fhem-web nutzt
Dann ändere das doch bitte im Wiki, falls dem so ist. Ich bin sehr zufrieden mit einer "Devices" config und einer "Services" Konfig und empfinde die Ordnung als sinnvoll. Jeder
save über FHEM-WEB führt dazu dass die jeweilige Datei geupdatet wird. Neue Devices, die ich über FHEM-WEB anlegen werden erstmal in den fhem.cfg geschrieben und ich kann die später wegsortieren.
Lass mich aber gerne von anderen best-practices überzeugen. Config in Datenbank? Alles über die Web-UI machen bestimmt nicht, ich bin im Text Editor wesentlich schneller unterwegs als über irgendeine UI.
Zitat von: chris1284 am 06 März 2017, 08:20:21
verlässt sich nie blind auf ein backup
Hab ich ja geschrieben - zum Glück konnte ich zwei Tage alte Backups finden, die nicht mit FHEM gemacht wurden.
Zitat von: automatisierer am 06 März 2017, 08:22:55
Entpacke ich die Datei über die Konsole mit tar, dann habe ich die Ordner wunderhübsch im Originalformat mit allen Dateien .
nd alles in die fhem.cfg kopiert und die ganzen includierten .cfg Dateien beseitigt.
Gute Idee! Das habe ich sofort ausprobiert und es
liegt am Archivprogramm! Tar enptackt die Dateien perfekt, andere Archivprogramme irgendwie nicht. Sehr komisch dass es nur bei den eigenen *.cfg Dateien der Fall ist. Dies funktioniert:
tar xvzf backup.tar.gzAlso anscheinend
kein Worst-Case Bug. Wieso diese paar cfg-Dateien die einzigen sind die mit 0KB herauskommen... keine Ahnung. Wenn ich das Entpacken mit 7-Zip mache auf Windows bekomme ich die Frage ob die CFG Dateien mit einer 0KB Version überschrieben werden sollen - automatisierer schreibt auch von doppelt vorkommenen Dateien. Anscheinend ist genau das ein Problem. Dass die include Dateien doppelt vorkommen und die "zweite 0KB Version" die erste überschreibt.
Zitat von: CoolTux am 06 März 2017, 08:32:21
Das entscheidende ist die Aussage
Bevor ein Update gemacht wird werden die jeweiligen Dateien welche ein Update erfahren gesichert. Das sollten in der Regel nur Programmodule sein.
Oder ich habe es falsch verstanden.
die Backups mache ich auch genau so und da is alles mit drin. Zum Zeitpunkt des Backups weiss FHEM ja auch noch gar nicht welche Dateien nen update bekommen...
un so schauts aus:
2017.03.06 08:35:00.080 2: Backup with command: tar -cf - "./backup" "./CHANGED" "./configDB.pm" "./contrib" "./coprocessor_update_hm_only.eq3" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.old" "./fhem.pl" "./fhem.pl.old" "./HLF10_2017-01.log" "./HLF10_2017-25.log" "./HM-LC-Sw1PBU-FM_update_V2_8_2_150713.tgz" "./log" "./README_DEMO.txt" "./regSave.cfg" "./restoreDir" "./tempList.cfg" "./tempList.cfg.log" "./unused" "./www" "./ZWDongle_1.bin" |gzip > /media/Backup/FHEM_CFG/FHEM-20170306_083500.tar.gz :o ... muss wohl mal wieder aufräumen...
Zitat von: chris1284 am 06 März 2017, 08:20:21
hier müsste im wiki ehr stehen: Hinweis: Die Verwendung des Befehls include gehört zum "Anfängermodus" da ein fhem experte wüsste, das man die DEF funktion im fhem-web nutzt um anpassungen zu machen und somit die vermeintliche ordnung durch aufteilenm der cfgs völlig sinnfrei ist
Nein, das ist so in dieser Allgemeinheit nicht richtig. Ich stimme dem Pareto-Ansatz zu (für 80%-90% der User ist include nicht benötigt und die Weboberfläche ausreichend, aber bei 10-20% macht es eventuell Sinn)...
Die Welt ist nicht Schwarz-Weiß.
Ciao, -MN
Zitat von: Morgennebel am 06 März 2017, 09:31:17
macht es eventuell Sinn)...
machen wir ein evtl, vielleicht, sehr selten, fast nie drauß ;)
Zitatich bin im Text Editor wesentlich schneller unterwegs als über irgendeine UI.
was zu beweisne wäre (aber nicht hier und heute, die diskussion gibts ja hier seitenweise) da du in der ui auch nur text im browser eingibst statt im editor...
Zitat von: chris1284 am 06 März 2017, 13:37:55
machen wir ein evtl, vielleicht, sehr selten, fast nie drauß ;)
Nun, ich bin so ein Spezialfall. Mein FHEM ist über WiFi angebunden, gerade an der Grenze der Reichweite. Trotz +5dBI-Antenne erreiche ich schwankend 1-8 MBit/s.
Die Größe der fhem.cfg wird damit ein Problem, denn diese muß vollständig geladen sein, bevor man Speichern drückt - sonst überschreibt die halbkomplette Version im Editor die komplette auf der Platte - zweimal passiert...
Anderes Beispiel ist die Homematic-Batteriestatus-Anzeige. Der Code muß mit Copy & Paste in die Datei, das klappt nie mit der Weboberfläche...
Ciao, -MN
PS Und ich komme aus der Unix-Welt. Ich MAG Dateien editieren anstatt eine Weboberfläche mit der Maus zu bedienen.
Zitat von: CoolTux am 06 März 2017, 08:32:21
Das entscheidende ist die Aussage
Bevor ein Update gemacht wird werden die jeweiligen Dateien welche ein Update erfahren gesichert. Das sollten in der Regel nur Programmodule sein.
Oder ich habe es falsch verstanden.
Was Du meinst ist /opt/fhem/restoreDir ;)
Nicht das Kommando backup, das sichert den /opt/fhem/
Zitat von: Morgennebel am 06 März 2017, 13:41:41
Anderes Beispiel ist die Homematic-Batteriestatus-Anzeige. Der Code muß mit Copy & Paste in die Datei, das klappt nie mit der Weboberfläche...
Du kennst schon dies hier? https://wiki.fhem.de/wiki/Import_von_Code_Snippets
Gruß Otto
Zitat von: Otto123 am 06 März 2017, 13:47:28
Was Du meinst ist /opt/fhem/restoreDir ;)
Nicht das Kommando backup, das sichert den /opt/fhem/
Gruß Otto
Richtig. Und genau das wird aber doch gemacht. Also Backup der Module nach RestoreDir wenn ich "backupBeforUpdate" auf 1 setze, oder?
PS: Otto Du hast Post ;)
Nö, das wird immer gemacht! backupBeforUpdate stellt sicher, das erst das backup Kommando ausgeführt wird, bevor update ausgeführt wird, welches ich in der Kommandozeile eingetragen habe. :D
Gruß Otto
Aha, siehste da es wieder mein NichtVerständnis. Danke fürs aufklären.
da gibbet aber auch in der Commandref nachholbedarf, backupBeforUpdate wird da mal so gar nicht erwähnt...
naja schreibt sich so: backup_before_update und steht bei update (https://fhem.de/commandref_DE.html#update)
Zitatattr global backup_before_update
Also alles da :)
Ist wahrscheinlich ein sehr altes Attribute und stammt aus der Zeit bevor bei FHEM die ungarische Notation (https://de.wikipedia.org/wiki/Ungarische_Notation) Einzug hielt die Cooltux verwendet hat. Oder heißt die noch anders? Ich bin nicht sicher ...
Gruß Otto
Zitat von: Otto123 am 06 März 2017, 14:22:41
ungarische Notation (https://de.wikipedia.org/wiki/Ungarische_Notation)
was es nicht alles gibt...
Nun ja, ich hatte nur unter global gesucht, auf update war ich so spontan nicht gekommen...
ich finde es auch nicht zwingend logisch das ein attribute für update unter global gehalten wird aber unter update beschrieben wird. Irgendwie ist da was unvollkommen, aber was ist schon vollkommen. ::)
Gruß Otto