Backup in FHEM neue Linux Funktion?!

eisman · 20 November 2025, 11:06:50

Hi,

unter welchen Namen kann man diese neue Linux-Funktion in Google finden:

in der Nacht unter 150 lux:

2025.11.20 05:00:00 3: FHEM.BackupOn return value: -1
/opt/backup bereits vorhanden
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=0.629 ms

--- 192.168.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.629/0.629/0.629/0.000 ms
192.168.1.2 erreichbar
/Q/backup bereits vorhanden
/Q/backup leer, Mounten starten
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
mountComplete: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
/etc/fstab: Eintrag bereits vorhanden: //192.168.1.2/backup /Q/backup cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0
Mounts werden aktualisiert
/Q/backup/FHEM/192.168.2.221 existiert bereits
251120_050000_fhem_backup.tar.gz (287 MB) wird in den Backupordner verschoben
8 Backups vorhanden - bis 15 aktuelle Backups werden vorgehalten
Mount wieder unmounten

am Tag mit mindestens 150 lux:

Code Auswählen

2025.11.20 05:37:09 3: MQTT2_DEVICE set LD_0111 off
2025.11.20 05:37:09 3: MQTT2_DEVICE set LD_0121 off
2025.11.20 05:37:09 3: MQTT2_DEVICE set LD_0131 off
2025.11.20 05:37:09 3: MQTT2_DEVICE set LD_0141 off
2025.11.20 06:00:00 3: CUL_HM set TC_0101_Climate desired-temp 20.0
2025.11.20 06:00:00 3: CUL_HM set TC_0201_Climate desired-temp 20.0
2025.11.20 06:00:00 3: CUL_HM set TC_0301_Climate desired-temp 18.0
2025.11.20 06:00:00 3: CUL_HM set TC_0401_Climate desired-temp 18.0
2025.11.20 06:00:00 3: CUL_HM set TC_0501_Climate desired-temp 18.0
2025.11.20 06:00:00 3: CUL_HM set RO_0401 pct 100
2025.11.20 08:00:00 3: CUL_HM set RO_0101 pct 25
2025.11.20 08:00:00 3: CUL_HM set RO_0201 pct 25
2025.11.20 08:00:00 3: CUL_HM set RO_0301 pct 100
2025.11.20 08:05:24 3: CUL_HM set TC_0101_Climate desired-temp 6.0
2025.11.20 08:05:37 3: CUL_HM set TC_0201_Climate desired-temp 6.0
2025.11.20 08:05:57 3: CUL_HM set TC_0301_Climate desired-temp 6.0
2025.11.20 08:13:04 3: CUL_HM set TC_0401 getConfig noArg
2025.11.20 08:13:37 3: CUL_HM set TC_0401_Climate desired-temp 20.0
2025.11.20 08:14:11 3: CUL_HM set TC_0501_Climate desired-temp 18.0
2025.11.20 08:16:39 3: CUL_HM set TC_0401_Climate desired-temp 21.0
2025.11.20 08:19:24 3: CUL_HM set TC_0501_Climate statusRequest noArg
2025.11.20 08:23:00 3: FHEM.BackupOn return value: -1
/opt/backup bereits vorhanden
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=127 time=0.708 ms

--- 192.168.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.708/0.708/0.708/0.000 ms
192.168.1.2 erreichbar
/Q/backup bereits vorhanden
/Q/backup nicht leer, kein Mounten notwendig
/Q/backup/FHEM/192.168.2.221 existiert bereits
251120_082300_fhem_backup.tar.gz (287 MB) wird in den Backupordner verschoben
9 Backups vorhanden - bis 15 aktuelle Backups werden vorgehalten
Mount wieder unmounten
2025.11.20 08:29:51 3: CUL_HM set TC_0301_Climate desired-temp 18.0

mal Spaß bei Seite: Netzwerk komplett erneuert

jetzt UDM Pro Max mit allen Netzwerk-Komponenten
alte System komplett entfernt und dennoch solche Fehler.
Zeit Verschiebungen auf UTC, Backup Meldungen diese Fehler kommen
immer nach der Zwangs Trennung und ca. 08:00Uhr in der restlichen zeit
funktioniert das ganze ohne Probleme.

vielleicht hat ja jemand eine Idee
Gruß

betateilchen · 20 November 2025, 12:53:20

Versteht jemand den vorherigen Beitrag? *grübel*

DeeSPe · 20 November 2025, 12:58:20

Zitat von: betateilchen am 20 November 2025, 12:53:20Versteht jemand den vorherigen Beitrag? *grübel*

Ich überlege auch seit >60min was uns hiermit gesagt/gefragt werden soll!?

Gruß
Dan

Otto123 · 20 November 2025, 13:19:49

Klingt nach Stromschwankungen in der KI

Aus Verzweiflung die Frage: bitte ein list FHEM.BackupOn

rabehd · 20 November 2025, 14:52:18

und ich dachte einfach, ich bin nicht intelligent genug dafür

tomcat.x · 20 November 2025, 16:18:46

Zitat von: Otto123 am 20 November 2025, 13:19:49Klingt nach Stromschwankungen in der KI

Glaube nicht, ist ja kein neuer Teilnehmer.

Wenn ich den Text unter den Logs richtig verstehe, müsste der Fehler im 2. Log sein (nach "8.00 Uhr"). Und irgendwas ist mit den Zeitstempeln nicht in Ordnung. Ist aber mit den Umbrüchen und fehlenden (?) Kommas nicht gut zu lesen. Vielleicht ist es auch anders rum und im ersten Log is das was nicht passsen soll. Ich kann es aber auch nicht erkennen.

Prof. Dr. Peter Henning · 20 November 2025, 16:33:15

Die Cannabis-Freigabe in Deutschland treibt seltsame Blüten.

LG

pah

Otto123 · 20 November 2025, 18:08:36

Zitat von: tomcat.x am 20 November 2025, 16:18:46Glaube nicht, ist ja kein neuer Teilnehmer.

Ich meinte ja nicht den Fragesteller, aber möglicherweise hat der KI Helfer bei der Formulierung der Frage Probleme gehabt.

Aber bei derart wirren Formulierungen kann man alles vermuten

enno · 20 November 2025, 18:26:58

Moin,

ich habe mir mal ein paar Gedanken machen lassen

Offene oder wiederkehrende Setzungen von Climate-Objekten (TC_..._Climate) mit unterschiedlichen Werten:

Das kann normal sein, wenn Automationen die Zieltemperatur anpassen. Wenn es zu unerwarteten Werten oder ständigen Änderungen kommt, prüfe deine Skripte/Auslöser (Zeitpläne, Regeln, HomeKit/HomeKit-Szenen, Thermostat-Skalierungen).
Die Meldungen von FHEM.BackupOn bzw. Backup-Operationen:

"FHEM.BackupOn return value: -1" und weitere Backup-Folgen deuten darauf hin, dass ein Backup-Vorgang fehlschlägt oder nicht wie erwartet durchgeführt wird.
Prüfe, ob das Backup-Verzeichnis existiert, Schreibrechte vorhanden sind und genügend Speicherplatz vorhanden ist.
Prüfe die Backup-Skripte bzw. den Mount/Zugang zu dem Ziel (Q/Backup) und ob Netzwerkpfade erreichbar sind.
Ping/Mount-Benachrichtigungen:

Erreichbarkeit des Remotes scheint vorhanden, aber es gibt Meldungen wie "Mount wieder unmounten" – prüfe, ob das Mounten von Backup-Verzeichnissen stabil läuft (Netzwerkpfade, Berechtigungen, Timeout). Instabile Mounts können zu Backup-Fehlern führen.
Allgemeine Hinweise:

Falls du gerade eine neue Automationsregel oder Änderung implementiert hast, teste schrittweise, ob eine einzelne Regel das Verhalten verursacht.
Prüfe Log-Dateien genauer zu Zeitpunkten der unerwarteten Änderungen, um den Bannkreis auf eine Komponente zu setzen (CUL_HM, FHEM-Backup, Netzwerk, Wetter-/Temp-Skripte).
Wenn du mir sagst:

Welche Komponente/system exakt betroffen ist (FHEM, CUL_HM, MQTT, Backup-Skript),
Welche Werte du erwartest vs. was tatsächlich passiert,
Welche Hardware/Software-Versionen konkret im Einsatz sind,
dann erstelle ich dir eine gezielte Fehlersuche mit konkreten Prüf-Schritten und passenden Konfig-Beispielen.

Ich würde den Teil mit dem Mount mal prüfen.

Gruss
Enno

eisman · 20 November 2025, 19:52:34

nö,

ist eine sehr einfache frage,
wenn ich das Backup manuell starte funktioniert es ohne Probleme,
wenn ich es über das Modul at um 5:00 Uhr (egal welche zeit zwischen 0 und 6 Uhr) starte kommen Fehler.
(ich habe es jetzt mal vor 0 Uhr gesetzt)

Code Auswählen

defmod FHEM.BackupAT at *23:00:00 { fhem ("set FHEM.Backup on");;}
attr FHEM.BackupAT DbLogExclude .*
attr FHEM.BackupAT comment # *05:00:00 { if ($wday == 4) { fhem ("set FHEM.Backup on");; }}
attr FHEM.BackupAT devStateStyle style="text-align:right;;;;"
attr FHEM.BackupAT room system

Code Auswählen

defmod FHEM.BackupOn notify FHEM.Backup:on {system ("sudo -u root /opt/fhem/FHEM/backup.sh &")}
attr FHEM.BackupOn DbLogExclude .*
attr FHEM.BackupOn room system

ich habe das gesamte Netzwerk ausgetauscht, also keine Kabel und auch keine Hardware Probleme,
und dennoch tritt der Fehler Sporadische auf, leider nicht immer an der selben stelle, sondern jedes mal an einer anderen stelle, wie eben das Backup auch. Protokolle geändert, dennoch die selben Probleme...

mountComplete="//$mountIp/$mountDir $localMountPoint cifs vers=3.0,credentials=/opt/fhem/.mntcred,iocharset=utf8 0 0"

Heute habe ich den Zigbee2Mqtt rausgenommen und durch deConz ersetzt.

@Enno
>> Offene oder wiederkehrende Setzungen von Climate-Objekten (TC_..._Climate) mit unterschiedlichen Werten:<<
>> es geht um die beiden Backup Einträge alles andre läuft Perfekt, wie ich es von FHEM kenne

gruss

eisman · 20 November 2025, 20:28:48

Hi Enno,

eigentlich gibt es nur 2 Probleme, DNS und Debian

die Zeit Verschiebung sind immer maximal 1-5 sek
von locale Zeit auf utc,
maximal 2 bis 3 mal in 24 Stunden ohne Netzwerkausfälle.
vor dem umstieg auf unifi, waren es 5 bis 20 mal in 24 Stunden,
inclusive massiver Netzwerk (meisten WLAN) ausfällen.

es gibt keine Einträge in den Logs, die auf Fehler hinweisen,
bei auftreten des Fehlers im Plot (anders kann man das Problem nicht sehen)
und dann den vergleich zwischen verschiedenen FHEM Installation.
ergab das in den gleichen log's auf verschiedenen Rechnern
nur ein (nie der selbe) Rechner betroffen ist, @pah
Die Cannabis-Freigabe wäre da wohl die bessere Wahl ...
jedenfalls kostet das keine nerven!

gruss