Werden keine Backups von Config-Dateien in include angelegt?!

[moontear]

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.

[moontear]

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

[chris1284]

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.

Hinweis: 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

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

[automatisierer]

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:

.... 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.

[CoolTux]

Das entscheidende ist die Aussage

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.

[moontear]

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.

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.

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.

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:

Code Auswählen Erweitern

tar xvzf backup.tar.gz

Also 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.

[automatisierer]

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:

Code Auswählen Erweitern

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

... muss wohl mal wieder aufräumen...

[Morgennebel]

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

[chris1284]

macht es eventuell Sinn)...

machen wir ein evtl, vielleicht, sehr selten, fast nie drauß 

ich 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...

[Morgennebel]

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.

[Otto123]

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/

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

[CoolTux]

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 

[Otto123]

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. 

Gruß Otto

[CoolTux]

Aha, siehste da es wieder mein NichtVerständnis. Danke fürs aufklären.

[automatisierer]

da gibbet aber auch in der Commandref nachholbedarf, backupBeforUpdate wird da mal so gar nicht erwähnt...