Hallo zusammen,
wie der Titel schon sagt, würde ich gerne ein bestimmtes Verzeichnis auf das Vorhandensein einer bestimmten Datei überprüfen. Hintergrund ist der, dass ich einen Server betreibe, auf diesem legt mein FHEM Raspi u.a. Images der Speicherkarte als Backup ab. Ich hatte jetzt 2x mal den Fall, dass der Mount nicht verfügbar war (warum auch immer) und deshalt das Image auf die Speicherkarte des Raspi geschrieben wurde. Das Problem dabei ist, wenn die Speicherkarte voll ist, Gehen mir einige userReadings verloren, und meine Haussteuerung funktioniert nicht mehr wie gewohnt - da wichtige userReading halt fehlen.
Meine Idee war jetzt, in dem Verzeichnis eine Datei zu platzieren, deren Vorhandensein FHEM regelmäßig überprüft. Ist diese Datei nicht vorhanden, bedeutet das dass der mount wiedermal (warum auch immer) nicht verfügbar ist. Dann soll eine Meldung kommen.
Also es geht mir jetzt nur um das Überprüfen "ist datei x in verzeichnis y?", die Meldung über Telegram oder Pushover ist dann nicht mein Problem - das bekomm ich hin...
Vielen Dank schon mal für Eure Hilfe!
Wie legst du denn die Images vom PI an?
bash-Script?
Was nutzt du dazu, 'dd'? -> kritisch
Stoppst du laufende Dienste!!?
Z.B. fhem etc.
Wenn Script: bau das doch einfach dort ein...
Ansonsten kannst du per 'at' nat. auch den bash-Aufruf aufrufen und prüfen...
EDIT: es gibt auch "raspi_backup" (link muss ich mal suchen), das nutzt rsync oder tar und prüft (soweit ich das im Kopf hab), ob ein mount geklappt hat vor dem Backup...
Gruß, Joachim
Hi,
Du willst das in Perl?
https://perldoc.perl.org/functions/-X
Testbeispiel für die FHEM Kommandozeile
{-e './fhem.cfg' ? "Datei existiert":"Datei fehlt"}
Gruß Otto
Es ist ein bash Script, denke es nutzt dd. Bin mir aber nicht sicher. Dir Dienste beende ich vorher und starte sie nachher wieder. Müsste auch schon Mal ein Image wiederherstellen und das ging problemlos... Was gäbe es denn sonst noch, wenn dd "kritisch" ist?
Klar, um Script selber werde ich das auch einbauen, dass das Backuo gar nicht startet, wenn der mount fehlt. Aber ich hätte gerne zeitnah einen Info darüber.
@Otto: danke, das werde ich mal testen, lässt sich ja sicherlich auch in einem at nutzen.
Hatte ich ja genannt: rsync bzw. tar
Mit dem Vorteil, dass nur tatsächliche Daten gesichert werden statt komplettes Image.
Zurückspielen geht dann "auf alles", sofern der Platz vorhanden ist.
Allerdings reicht mit das fhem Backup...
Ich such mal nach dem Link...
EDIT: http://www.linux-tips-and-tricks.de/raspiBackup bzw. https://opensource.com/article/18/8/automate-backups-raspberry-pi
Gruß, Joachim
Was Du eigentlich willst ist doch prüfen ob der mount verfügbar ist, oder?
In bash ist das ähnlich:
if [ ! -e $file ]
then
echo "$file is missing"
fi
Wenn Du den mount erst im Script machst, kannst Du den Erfolg direkt testen:
if mount "$dpath"
then
echo "Mount $dpath war erfolgreich"
fi
Den mount mach in in der fstab. Warum der ab und an nicht da ist, hab ich noch nicht rausgefunden. Ich bekomme es ja auch erst einiges später mit.
Ja im Prinzip würde es reichen zu prüfen ob der mount da ist. Wenn man das in bash und Fhem ohne eine Datei abzufragen prüfen kann, wäre das natürlich ideal.
Zitat von: MadMax-FHEM am 05 April 2021, 20:55:26
Hatte ich ja genannt: rsync bzw. tar
Mit dem Vorteil, dass nur tatsächliche Daten gesichert werden statt komplettes Image.
Zurückspielen geht dann "auf alles", sofern der Platz vorhanden ist.
Allerdings reicht mit das fhem Backup...
Ich such mal nach dem Link...
EDIT: http://www.linux-tips-and-tricks.de/raspiBackup bzw. https://opensource.com/article/18/8/automate-backups-raspberry-pi
Gruß, Joachim
Also ich mache ein Backup der FHEM config bereits mit über Fhem. Zusätzlich zieh ich noch regelmäßig ein Image der Speicherkarte, falls die mal das zeitliche segnet.
Ich mache den mount von Netzlaufwerken immer dann wenn ich ihn brauche. Alles andere ist mir zu unklar und kompliziert.
Die Backups mache ich nie direkt auf ein Netzwerklaufwerk.
- mount Netzlaufwerk,
- kopiere die Dateien mit rsync
- unmount.
Damit hat man eine einfache und klare Fehlerbehandlung.
Zitat von: brown78 am 05 April 2021, 22:55:36
Also ich mache ein Backup der FHEM config bereits mit über Fhem. Zusätzlich zieh ich noch regelmäßig ein Image der Speicherkarte, falls die mal das zeitliche segnet.
Nur fhem.cfg?
Was ist mit fhem.save und Passwörten/Token in uniqueID usw.?
Also ich nutze fhem backup und da packe ich alles rein was ich brauche.
Zusammen mit meinen Notizen brauche ich kaum länger ein neues System aufzusetzen als mit einem Image...
Und: es übt :)
Und macht einen "Umstieg" auf ein neues OS einfach...
Viel Erfolg, Joachim
Ich nutze schon Fhem Backup dafür. Ich hab jetzt einfach nur die config genannt, da ich nicht auswendig weiß, was da alles mit gesichert wird. Werd mir das morgen mal ansehen, wenn ich die Zeit habe, und am Rechner sitze.
@Otto: das Laufwerk erst zu mounten, wenn das Image gezogen wird, gefällt mir. Auch das Backup erst lokal zu sichern und dann zu übertragen, hat zumindest den Vorteil dass ich keine Backup verpasse wenn der mount fehlt. Trotzdem bräuchte ich dann eine ausreichend große Schoeicherkarte und trotz allem einen Hinweis wenn der mount nicht da ist. Aber wahrscheinlich bräuchte ich gar kein volles Image, wenn ich mich Mal damit befassen würde, was ich alles wirklich sichern muss. Ausser Fehm läuft noch deconz drauf, ansonsten so Zertifikat Zeug halt... Sobald mein Anycubic mir mal wieder Zeit lässt, befasse ich mich damit. Vielen Dank an euch für die Denkanstöße!
Zitatund trotz allem einen Hinweis wenn der mount nicht da ist.
Naja wie oben gezeigt - sieht vielleicht zu einfach aus?
if mount ... - ist nur wahr wenn der Befehl ohne Fehler abgeschlossen wurde.
Guten Morgen!
Also das Fhem Backup macht ein Script das per Cron ausgeführt wird, hier arbeite ich tatsächlich mit tar... es wird dabei das komplette Verzeichnis /opt/fhem gesichert.
Da habe ich jetzt einfach mal die Prüfung auf Vorhandensein der Datei eingebaut (werde das noch verbessern, also den mount erst dann machen - dazu brauche ich aber die Muse).
Die Warnung über Telegram oder Pushover steht noch aus.
Aber vielleicht könnt Ihr mir sagen was ich bei den UserReadings falsch mache, es werden bei einigen DOIFs gewisse UserReadings gespeichert manche aber nicht.
Ich habe mit setreading DEVICE READING VALUE Befehle hinterlegt, konkret:
setreading ctl_flur_aio auto_cmd set HM_Flur_Clima controlMode auto;; set HM_Flur_Clima burstXmit
Die Ausführung funktioniert, nur wenn die Speicherkarte im Raspi mal wieder voll läuft, sind diese readings weg. Andere UserReadings bleiben erhalten, diese enthalten dann nur bspw. "off" oder "18.0"...
Ein setreading IN einem userreadings am Ende noch auf "sich selbst": ganz böse ;)
Was soll denn im userreadings stehen bzw. was soll denn im Reading "auto_cmd" des Devices "ctl_flur_aio" stehen?
(zumindest deute ich deinen "Ausschnitt" so)
Und soll das 2te set ausgeführt werden!?
Und was soll: Die Ausführung funktioniert, nur wenn die Speicherkarte im Raspi mal wieder voll läuft, sind diese readings weg.
Ausführung von was?
userreadings? das 2te set?
Dass userreadings nicht gespeichert werden (bei voller Karte): je nachdem wann ein "save" ausgeführt wird und die aktuellen Zustäne in fhem.save geschrieben werden (können), sind sie da....
...oder auch nicht.
Denke aber nicht, dass es speziell an DIESEN Readings liegt bzw. warum es genau DA liegen sollte.
Wäre mMn eher "Zufall", also was eben gerade nicht mehr in fhem.save landet/landen kann (weil Karte voll)...
Aber wenn du dir mit einer Backup-Erstellung dein System "flach legst" (flach legen kannst, potentiell), dann würde ich die Backup-Strategie noch mal überdenken ;)
Gut: machst du ja gerade ;)
Wie geschrieben: mir reicht ein fhem Backup.
Das wird (nat. bei update) jeden Samstag erstellt und auf mein "NAS" gespeichert.
Aber: Backup wird LOKAL erstellt (fhem Backup braucht ja nicht so viel Platz) und dann eben auf das NAS kopiert (und genau zu diesem Zweck wird gemounted und wieder "unmounted") und auf dem NAS dann Backups von 2 Monaten aufgehoben, auf dem fhem Server immer nur der aktuelle Monat...
Ich arbeite zwar aktuell auch an einem "Komplett-Backup", das führe ich aber manuell aus und nur, wenn ich größere "Umbauten" mache und eigentlich nicht auf dem fhem Server (weil: es reicht mir fhem Backup ;) ), eher auf meinem Unifi Controller, wenn ich dann doch mal wieder einen Update von Unifi einspiele.
Bislang habe ich immer die SSD "geclont" (bzw. mittels tar "abgezogen") auf eine 2te SSD, dann getauscht und installiert.
Wenn alles gut ging: ok.
Wenn nicht: andere SSD wieder rein und auch gut :)
Da bin ich aktuell dran den "Abzug" (bzw. das "Clonen") im Betrieb durchzuführen.
Aber eben auch manuell und eigentlich nur, weil ich dann nicht immer die SSD "ausbauen" muss...
Und ja: manuell reicht, weil die Daten (und Configs) werden nat. autom. gesichert. Die Installation ist ja kein Ding (habe gute Notizen etc.) und dauert kaum länger als das Einspielen eines Komplett-Backup-Images...
Image einspielen muss ich eh, Raspi anpassen ist schnell erledigt und die paar zusätzlichen Pakete auch kein Ding und dann noch die gesicherten Configs zurück: done :)
Und eben, wenn ein OS Umzug ansteht, geht das genauso. Daher habe ich zwar (auch) keine (große) Lust "umzusteigen" aber es ist nicht anders als ein Restore, nur halt auf einem neuen OS (und evtl. sogar HW)... ;)
Viel Spaß, Joachim
Also Moment, das setreading steh natürlich nicht im userReading. Das habe ich über die Komandozeile eingegeben.
Wie zu erkennen sein sollte ist das DOIF für HM Thermostate zuständig und schaltet abhängig von Fensterkontakten und Temperaturen auf auto, aus, boost oder sommer.
Daher habe ich die Befehle dazu in userReadings gepackt.
auto_cmd: set HM_Flur_Clima controlMode auto; set HM_Flur_Clima burstXmit
Diese Kommandos werden entsprechend korrekt ausgeführt, also alle verschiedenen und auch die 2. Teile. Nur bleiben die eben nicht erhalten. Die ändern sich aber auch nicht. Also wenn das einmal in einer fhem.save stand (gehe ich davon aus, weil Neustarts "entfernen" die userReadings nicht), wäre es eigentlich egal ob mal ein save nicht laufen kann.
Aber was mir da gerade kommt, dann müsste es doch gehen, dass ich eine fhem.save aus einem Backup zurückspiele.... werd ich mal testen...
Was du hier hast sind KEINE userReadings!
EDIT: außer das was du schreibst stimmt nicht, weil du "verwirrend" schreibst... Wenn wirklich userreadings, dann poste doch mal ALLES... Nicht immer nur so "halbe Sachen"...
Was du hast sind eher: selbst "angelegte" (durch setreading) Readings!
userReadings sind durch Attribute "angelegte" Readings BEI einem Device!
https://wiki.fhem.de/wiki/UserReadings
https://forum.fhem.de/index.php?topic=10254.0
Aber auch die durch setreading "angelegten" Readings sollten erhalten bleiben...
...außer: DOIF "tickt" hier anders...
Da ich aber DOIF nicht nutze: keine Ahnung ;)
Du kannst ja mal den/die setreading ausführen und schauen, ob sie dann als Reading wie gewünscht im DOIF stehen. Dann shutdown restart (dabei wird [bei nicht voller Karte ;) ] ein save ausgeführt) und schauen, ob sie immer noch da sind... Sollten sie mMn...
Zumindest funktioniert das bei meinen dummy auf meinem Testsystem...
EDIT: eben getestet "setreading beispiel_jet meinNeuerTest set Dev123 manu" dann shutdown restart und das Reading ist immer noch da... Also bei meinem "Test-dummy"...
EDIT: eben wollte ich DEIN setreading nachspielen "setreading beispiel_jet auto_cmd: set HM_Flur_Clima controlMode auto; set HM_Flur_Clima burstXmit" allerdings scheitert das schon am Reading-Namen "auto_cmd:"... Ich bin nicht sicher (wie bereits geschrieben), ob das was du da postest auch das ist was du tust bzw. unklar WIE/WO du das machst...
EDIT: warum schickst du burst hinterher? Machst du das immer? Weil dann kannst du auch "auto-burst" setzen ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 06 April 2021, 10:42:03
Was du hier hast sind KEINE userReadings!
Was du hast sind eher: selbst "angelegte" (durch setreading) Readings!
userReadings sind durch Attribute "angelegte" Readings BEI einem Device!
https://wiki.fhem.de/wiki/UserReadings
https://forum.fhem.de/index.php?topic=10254.0
Aber auch die durch setreading "angelegten" Readings sollten erhalten bleiben...
...außer: DOIF "tickt" hier anders...
Da ich aber DOIF nicht nutze: keine Ahnung ;)
Du kannst ja mal den/die setreading ausführen und schauen, ob sie dann als Reading wie gewünscht im DOIF stehen. Dann shutdown restart (dabei wird [bei nicht voller Karte ;) ] ein save ausgeführt) und schauen, ob sie immer noch da sind... Sollten sie mMn...
Zumindest funktioniert das bei meinen dummy auf meinem Testsystem...
Gruß, Joachim
Ok, ja stimmt sorry für die Verwirrung. Habe eine alte fhem.save aus einem Backup geöffnet und da sind die readings drin. Versuche jetzt mal diese einzuspielen.
Edit: das reading heißt auto_cmd ohne ":"
Edit: das burstXmit schicke ich nur bei Befehlen die zeitnah ausgeführt werden sollen, also nicht mei allen.
Zitat von: brown78 am 06 April 2021, 10:49:43
Ok, ja stimmt sorry für die Verwirrung. Habe eine alte fhem.save aus einem Backup geöffnet und da sind die readings drin. Versuche jetzt mal diese einzuspielen.
Edit: das reading heißt auto_cmd ohne ":"
Edit: das burstXmit schicke ich nur bei Befehlen die zeitnah ausgeführt werden sollen, also nicht mei allen.
Tja ;)
Zeitnah werden alle Befehle ausgeführt.
Eigentlich spät. nach ca. 3min...
Reicht das nicht für auto? ;)
Allerdings ist das jetzt schon ziemlich weit OT...
...es ist aber ja "dein" Thread...
Gruß, Joachim
Ja für auto würde das reichen. Für "Fenster" allerdings etwas lange...
Zurück zum Thema: Die alte fhem.save hat mir einigen an Tipparbeit erspart. Danke für den Hinweis, dass die readings in der fhem.save stehen!
Jetzt kann ich entspannt über meine Backup Strategie nachdenken! ;D