NEWS
TESTER gesucht / Backup auf Fritz.nas - node 18.18.0
-
Wir können für den Anfang erstmal festhalten, dass es nicht an Backitup liegt und mir aktuell bekannt, nur in Verbindung mit der FRITZ!Box die Probleme auftreten.
Wäre gut, wenn andere ohne Fritz NAS hier auch noch Ihre Ergebnisse teilen könnten. So können wir gezielt eingrenzen..
@Thomas-Braun
Hast du noch ne Idee, ob wir im Mount noch zusätzliche Parameter testen können?@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Hast du noch ne Idee, ob wir im Mount noch zusätzliche Parameter testen können?
Ich bin komplett ratlos. Es muss aber mit tar und/oder gzip in Verbindung stehen. Bereits gepackte Backup kann ich z. B. auf die Freigabe schieben.
-
Wir können für den Anfang erstmal festhalten, dass es nicht an Backitup liegt und mir aktuell bekannt, nur in Verbindung mit der FRITZ!Box die Probleme auftreten.
Wäre gut, wenn andere ohne Fritz NAS hier auch noch Ihre Ergebnisse teilen könnten. So können wir gezielt eingrenzen..
@Thomas-Braun
Hast du noch ne Idee, ob wir im Mount noch zusätzliche Parameter testen können?@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Wir können für den Anfang erstmal festhalten, dass es nicht an Backitup liegt und mir aktuell bekannt, nur in Verbindung mit der FRITZ!Box die Probleme auftreten.
Wäre gut, wenn andere ohne Fritz NAS hier auch noch Ihre Ergebnisse teilen könnten. So können wir gezielt eingrenzen..
@Thomas-Braun
Hast du noch ne Idee, ob wir im Mount noch zusätzliche Parameter testen können?Nein, das hat auch niemand behauptet. Am Adapter liegt es nicht, aber am js-controller dessen Routinen der Adapter mW nutzt. D.h. mit manuellem cifs mount und
iob backupgibt es auf betroffenen Systemen den gleichen Fehler. Und im Controller ist auch nichts wirklich falsch, aber in Kombination mit writableStream und pipe treten auf manchen Systemen halt Fehler auf. Wenn ich das tar.gz erstelle und dann kopiere tritt der Fehler nicht auf(Hier im Skript versehentlich geändert) Wir haben schon so ziemlich alle Kombinationen ohne Erfolg durch, bei mir zB klappt es immer :-( Wir hatten auch mit Erfolg gzip: false getestet und der Fehler war weg. Hier im Skript klappt das aber plötzlich nicht mehr. Um diese Fummelei an Systemdaten zu vermeiden und einen grösseren Userkreis mit einzubinden gibt es dieses Skript -
@thomas-braun sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
ist das die gleiche Config mit der wir die Tage getestet hatten?
Ja, im Grund schon. Ich mounte über die fstab allerdings mit smbcredentials statt user/pw, aber das sollte keinen Unterschied machen, die Freigabe landet ja im Mountpunkt.
ich dachte da eher an andere(ältere) Hardware. Für die Alternate Methode habe ich ne Erklärung, wir hatten mit Erstellen und dann kopieren getestet, jetzt schreibe ich das gleich in den mount, werde ich ändern. Aber uncompressed im Adapter hatte funktioniert und mit Skript nicht.
Wenn der Mount immer besteht, wie handelst du das im Adapter, der mounted doch auch immer? Dazu könntest du aber NAS/COPY ausschalten und 'normal' ein Backup machen, geht ja dann als Standard in den mountpoint. Als Alternative dazu NAS/COPY von cifs auf copy umstellen und als Pfad /opt/iobroker/backups einstellen. Wäre interessant zu sehen ob das einen Unterschied macht.
OT: Wie sieht denn der Eintrag im fstab aus? incl. der smb-credentials bitte, ohne PW narürlich
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Wenn der Mount immer besteht, wie handelst du das im Adapter, der mounted doch auch immer?
Nein, der mount besteht nicht immer. Der ist nur in der fstab eingetragen, damit ein simples 'mount /opt/iobroker/backups' funktioniert und ich nicht immer alle Optionen angeben muss. Bin doch ein Fauler... ;-)
Der Eintrag:
# iobroker Backup //192.168.178.1/FRITZ.NAS/Hitachi-HTS545012B9SA00-01/iobbackups/chet /opt/iobroker/backups cifs credentials=/home/iobroker/.smbcredentials,users,noserverino,rw,noauto,uid=iobroker,gid=iobroker,file_mode=0777,dir_mode=0777,vers=3.1.1 -
Kannst du mal bitte den Mount manuell setzen und die Optionen probieren?
- cache: Die Deaktivierung des Caches cache=none kann helfen, falls die SMB-Freigaben nicht korrekt eingehangen werden.
- nobrl: Deaktivierung der Bytebereich-Sperrung (Byte-Range Lock). Einige Programme kommen mit dem Byte-Range Lock nicht zurecht und können deshalb auf gemountete SMB-Freigaben trotz korrekter Berechtigungen nicht schreiben. Abhilfe schafft hier die Mount-Option nobrl.
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Kannst du mal bitte den Mount manuell setzen und die Optionen probieren?
- cache: Die Deaktivierung des Caches cache=none kann helfen, falls die SMB-Freigaben nicht korrekt eingehangen werden.
- nobrl: Deaktivierung der Bytebereich-Sperrung (Byte-Range Lock). Einige Programme kommen mit dem Byte-Range Lock nicht zurecht und können deshalb auf gemountete SMB-Freigaben trotz korrekter Berechtigungen nicht schreiben. Abhilfe schafft hier die Mount-Option nobrl.
Der Fehler trat bei Thomas erst mit der 18.18.0 auf und mit node 20, wir hatten bzw haben gzip in Verdacht, da wurde in der neuen node was geändert
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Wenn der Mount immer besteht, wie handelst du das im Adapter, der mounted doch auch immer?
Nein, der mount besteht nicht immer. Der ist nur in der fstab eingetragen, damit ein simples 'mount /opt/iobroker/backups' funktioniert und ich nicht immer alle Optionen angeben muss. Bin doch ein Fauler... ;-)
Der Eintrag:
# iobroker Backup //192.168.178.1/FRITZ.NAS/Hitachi-HTS545012B9SA00-01/iobbackups/chet /opt/iobroker/backups cifs credentials=/home/iobroker/.smbcredentials,users,noserverino,rw,noauto,uid=iobroker,gid=iobroker,file_mode=0777,dir_mode=0777,vers=3.1.1@thomas-braun sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Der Eintrag:
Danke! und der Aufbau der credentials Datei?
-
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Kannst du mal bitte den Mount manuell setzen und die Optionen probieren?
- cache: Die Deaktivierung des Caches cache=none kann helfen, falls die SMB-Freigaben nicht korrekt eingehangen werden.
- nobrl: Deaktivierung der Bytebereich-Sperrung (Byte-Range Lock). Einige Programme kommen mit dem Byte-Range Lock nicht zurecht und können deshalb auf gemountete SMB-Freigaben trotz korrekter Berechtigungen nicht schreiben. Abhilfe schafft hier die Mount-Option nobrl.
Der Fehler trat bei Thomas erst mit der 18.18.0 auf und mit node 20, wir hatten bzw haben gzip in Verdacht, da wurde in der neuen node was geändert
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein. -
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein.Mit nobrl und cache=none
echad@chet:/opt/iobroker $ mount | grep FRITZ //192.168.178.1/FRITZ.NAS/Hitachi-HTS545012B9SA00-01/iobbackups/chet on /opt/iobroker/backups type cifs (rw,nosuid,nodev,noexec,relatime,vers=3.1.1,cache=none,username=iobroker,uid=1001,noforceuid,gid=1001,noforcegid,addr=192.168.178.1,file_mode=0777,dir_mode=0777,soft,nounix,mapposix,nobrl,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=5) echad@chet:/opt/iobroker $ ls -lAh backups/ total 296K -rwxrwxrwx 1 iobroker iobroker 0 Oct 4 18:16 01_FREIGABE_FRITZ_NAS -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:46 2023_10_04-18_46_20_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:17 test_alternative.tar.gz -rwxrwxrwx 1 iobroker iobroker 246K Oct 4 18:17 test_nocompression.tar -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:17 test_standard.tar.gz echad@chet:/opt/iobroker $ -
Mit nobrl und cache=none
echad@chet:/opt/iobroker $ mount | grep FRITZ //192.168.178.1/FRITZ.NAS/Hitachi-HTS545012B9SA00-01/iobbackups/chet on /opt/iobroker/backups type cifs (rw,nosuid,nodev,noexec,relatime,vers=3.1.1,cache=none,username=iobroker,uid=1001,noforceuid,gid=1001,noforcegid,addr=192.168.178.1,file_mode=0777,dir_mode=0777,soft,nounix,mapposix,nobrl,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=5) echad@chet:/opt/iobroker $ ls -lAh backups/ total 296K -rwxrwxrwx 1 iobroker iobroker 0 Oct 4 18:16 01_FREIGABE_FRITZ_NAS -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:46 2023_10_04-18_46_20_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:17 test_alternative.tar.gz -rwxrwxrwx 1 iobroker iobroker 246K Oct 4 18:17 test_nocompression.tar -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 18:17 test_standard.tar.gz echad@chet:/opt/iobroker $Die smbcredentials:
echad@chet:/opt/iobroker $ sudo -u iobroker cat /home/iobroker/.smbcredentials username=iobroker password=GehEImes_PassW0rtDa sehe ich kein Problem.
-
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein.@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein.Aber natürlich, besonders Deine Bemerkungen sind besonders willkommen. Wollte dich nur auf den Stand bringen den wir nach stundenlanger Testerei erreicht hatten. Dadurch wurde dann dieser thread hier
Was die Fritte betrifft so haben doch einige diese, wie man hier auch lesen kann. Auch ich habe eine (cable 6591(kdg), os=7.57) und keinerlei Probleme
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
Die smbcredentials:
echad@chet:/opt/iobroker $ sudo -u iobroker cat /home/iobroker/.smbcredentials username=iobroker password=GehEImes_PassW0rtDa sehe ich kein Problem.
@thomas-braun Da kann ich ja fast froh sein, meinen iobroker LXC Container unter Proxmox nicht privilegiert erstellt zu haben, und ich mir deshalb einen Workaround mit rsync ausdenken musste, um die lokalen Backups vom LXC-Container wegzuschaffen..
-
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein.Aber natürlich, besonders Deine Bemerkungen sind besonders willkommen. Wollte dich nur auf den Stand bringen den wir nach stundenlanger Testerei erreicht hatten. Dadurch wurde dann dieser thread hier
Was die Fritte betrifft so haben doch einige diese, wie man hier auch lesen kann. Auch ich habe eine (cable 6591(kdg), os=7.57) und keinerlei Probleme
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt? -
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot ja mir ist das Thema bekannt. Bin mit Thomas im Issue im Regen Austausch..
Es wäre sicher trotzdem sinnvoll die Mount Optionen mal zu testen.
Und am Ende scheint nur die Fritte betroffen zu sein.Aber natürlich, besonders Deine Bemerkungen sind besonders willkommen. Wollte dich nur auf den Stand bringen den wir nach stundenlanger Testerei erreicht hatten. Dadurch wurde dann dieser thread hier
Was die Fritte betrifft so haben doch einige diese, wie man hier auch lesen kann. Auch ich habe eine (cable 6591(kdg), os=7.57) und keinerlei Probleme
Nochmal zur Zusammfassung: Verhalten taucht bei nodejs@20 in allen Versionen auf, bei nodejs@18 erst ab 18.18.0.
'Normale' Dateioperationen wie cp oder mv in die Freigabe funktionieren immer.
Schreiben eines tar.gz führt zu leeren Dateien. -
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?
Ohne 'noserverino' funktioniert es wie gewohnt nicht mit dem fritz.nas. Hatte ich schon probiert.
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen. -
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?In der Vergangenheit hatte ich Thomas mal gebeten damit zu experimentieren und denke er hatte das auch gemacht. Bei mir selbst ist es egal was ich einstelle, ich kann den Fehler nicht provozieren. Hatte das auch mal ähnlich damals hatte noserverino einschalten geholfen, war aber auch ne andere Box
im Prinzip reden wir über das Verhalten durch Zeile 179 in node_modules/@iobroker/js-controller-cli/build/lib/setup/setupBackup.js
tar_1.default.create({ gzip: true, cwd: `${this.tmpDir}/` }, ['backup']).pipe(f);iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?
Ohne 'noserverino' funktioniert es wie gewohnt nicht mit dem fritz.nas. Hatte ich schon probiert.
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen.@thomas-braun sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen.
ist im Skript einstellbar(1.0, 2.0, 3.0, 3.0.2 und 3.1.1)
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@thomas-braun sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen.
ist im Skript einstellbar(1.0, 2.0, 3.0, 3.0.2 und 3.1.1)
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen.
Ich hab es in der fstab jeweils angepasst. Macht aber keinen Unterschied, was ich da angebe. Freies Aushandeln des Dialekts, die diversen Versionen angegeben, macht alles keinen Unterschied, das Backup ist jeweils nur 16KB groß. Ich glaube die mount-Optionen können wir ausschließen.
-
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Allerdings die SMB-Versionen hatte ich immer fix auf 3.1.1, da mit kann ich nochmal herumspielen.
Ich hab es in der fstab jeweils angepasst. Macht aber keinen Unterschied, was ich da angebe. Freies Aushandeln des Dialekts, die diversen Versionen angegeben, macht alles keinen Unterschied, das Backup ist jeweils nur 16KB groß. Ich glaube die mount-Optionen können wir ausschließen.
@thomas-braun könntest du mal die V2 testen, da ist jetzt erstellen/copy berichtigt, d.h. die test_alternative.tar.gz sollte jetzt richtig übertragen werden
-
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?In der Vergangenheit hatte ich Thomas mal gebeten damit zu experimentieren und denke er hatte das auch gemacht. Bei mir selbst ist es egal was ich einstelle, ich kann den Fehler nicht provozieren. Hatte das auch mal ähnlich damals hatte noserverino einschalten geholfen, war aber auch ne andere Box
im Prinzip reden wir über das Verhalten durch Zeile 179 in node_modules/@iobroker/js-controller-cli/build/lib/setup/setupBackup.js
tar_1.default.create({ gzip: true, cwd: `${this.tmpDir}/` }, ['backup']).pipe(f);@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?In der Vergangenheit hatte ich Thomas mal gebeten damit zu experimentieren und denke er hatte das auch gemacht. Bei mir selbst ist es egal was ich einstelle, ich kann den Fehler nicht provozieren. Hatte das auch mal ähnlich damals hatte noserverino einschalten geholfen, war aber auch ne andere Box
im Prinzip reden wir über das Verhalten durch Zeile 179 in node_modules/@iobroker/js-controller-cli/build/lib/setup/setupBackup.js
tar_1.default.create({ gzip: true, cwd: `${this.tmpDir}/` }, ['backup']).pipe(f);Hier wäre noch die Frage, um den js-controller auszuschließen, wie sich die anderen Backups verhalten. Backitup erstellt ja eigenständig ohne js-controller Backups wie z.B. influx oder JavaScript
Sind die Dateien auch betroffen?
-
@fastfoot sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
@fastfoot @Thomas-Braun
Habt ihr mal noserverino abgeschaltet und habt ihr mal mit den SMB Versionen gespielt?In der Vergangenheit hatte ich Thomas mal gebeten damit zu experimentieren und denke er hatte das auch gemacht. Bei mir selbst ist es egal was ich einstelle, ich kann den Fehler nicht provozieren. Hatte das auch mal ähnlich damals hatte noserverino einschalten geholfen, war aber auch ne andere Box
im Prinzip reden wir über das Verhalten durch Zeile 179 in node_modules/@iobroker/js-controller-cli/build/lib/setup/setupBackup.js
tar_1.default.create({ gzip: true, cwd: `${this.tmpDir}/` }, ['backup']).pipe(f);Hier wäre noch die Frage, um den js-controller auszuschließen, wie sich die anderen Backups verhalten. Backitup erstellt ja eigenständig ohne js-controller Backups wie z.B. influx oder JavaScript
Sind die Dateien auch betroffen?
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Sind die Dateien auch betroffen?
Das kann ich gar nicht sagen, bisher tatsächlich nur konzentriert auf das iobroker backup. Falls diese Dateien aber nicht betroffen wären dann hätten wir ja auch schon die Lösung :-)
@Thomas-Braun kannst Du mal Javascript mit reinpacken?
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@simatec sagte in TESTER gesucht / Backup auf Fritz.nas - node 18.18.0:
Sind die Dateien auch betroffen?
Das kann ich gar nicht sagen, bisher tatsächlich nur konzentriert auf das iobroker backup. Falls diese Dateien aber nicht betroffen wären dann hätten wir ja auch schon die Lösung :-)
@Thomas-Braun kannst Du mal Javascript mit reinpacken?
Es sind alle Backuptypen betroffen:
echad@chet:/opt/iobroker $ ls -lah backups/ | grep '20_06\|20_05' -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 20:07 historyDB_2023_10_04-20_06_45_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 16K Oct 4 20:06 iobroker_2023_10_04-20_06_34_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 0 Oct 4 20:05 javascripts_2023_10_04-20_05_20_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 0 Oct 4 20:05 zigbee.0_2023_10_04-20_05_19_chet_backupiobroker.tar.gzWas mir im Log auffällt:
Started iobroker ... [DEBUG] [mount] - noserverino option: true [DEBUG] [mount] - cifs-mount command: "sudo mount -t cifs -o username=iobroker,password=****,noserverino,rw,uid=iobroker,gid=iobroker,file_mode=0777,dir_mode=0777,vers=3.1.1 //fritz.nas/fritz.nas/Hitachi-HTS545012B9SA00-01/iobbackups/chet /opt/iobroker/backups" [DEBUG] [mount] - mount successfully completed [DEBUG] [mount] - done [DEBUG] [iobroker] - host.chet 8104 states saved [DEBUG] [iobroker] - host.chet 9932 objects saved [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2023_10_04-20_06_34_chet_backupiobroker.tar.gz [DEBUG] [iobroker] - This backup can only be restored with js-controller version up from 4.1 [DEBUG] [iobroker] - done [DEBUG] [historyDB] - compress from historyDB started ... [DEBUG] [historyDB] - Packed 0MB so far... [DEBUG] [historyDB] - Backup created: /opt/iobroker/backups/historyDB_2023_10_04-20_06_45_chet_backupiobroker.tar.gz [DEBUG] [historyDB] - done [DEBUG] [zigbee] - found zigbee database: zigbee.0 [DEBUG] [zigbee] - done [DEBUG] [javascripts] - Created javascript_tmp directory: "/opt/iobroker/backups/tmpScripts" [DEBUG] [javascripts] - found Script: dwd_uwz_nina_warnungen [DEBUG] [javascripts] - found Script: lautstaerke_bad [DEBUG] [javascripts] - found Script: lautstaerke_kueche [DEBUG] [javascripts] - found Script: paketlieferungen [DEBUG] [javascripts] - found Script: pakettruhe_offen [DEBUG] [javascripts] - found Script: ps4_waker [DEBUG] [javascripts] - found Script: sonnenaufgang [DEBUG] [javascripts] - found Script: sonnenuntergang [DEBUG] [javascripts] - found Script: speedtest [DEBUG] [javascripts] - found Script: telefon_klingelt [DEBUG] [javascripts] - found Script: treppenhaus_licht_ble [DEBUG] [javascripts] - found Script: treppenhaus_licht_hub [DEBUG] [javascripts] - found Script: tuerklingel_laeutet [DEBUG] [javascripts] - found Script: wohnung_verlassen [DEBUG] [javascripts] - found Script: zuhause_verlassen [DEBUG] [javascripts] - found Script: nuki_ext_wohnungstuer_entriegelt [DEBUG] [javascripts] - found Script: stromzaehler [DEBUG] [javascripts] - found Script: stromzaehler2 [DEBUG] [javascripts] - found Script: frostwarner [DEBUG] [javascripts] - found Script: awtrix [DEBUG] [javascripts] - Try deleting the Javascript tmp directory: "/opt/iobroker/backups/tmpScripts" [DEBUG] [javascripts] - Javascript tmp directory "/opt/iobroker/backups/tmpScripts" successfully deleted [DEBUG] [javascripts] - Backup created: /opt/iobroker/backups/javascripts_2023_10_04-20_07_12_chet_backupiobroker.tar.gz [DEBUG] [javascripts] - done [DEBUG] [cifs] - used copy path: /fritz.nas/Hitachi-HTS545012B9SA00-01/iobbackups/chet [DEBUG] [cifs] - done [DEBUG] [clean] - No older backup files are deleted, because this backup was started manually [DEBUG] [clean] - done [DEBUG] [whatsapp] - done [DEBUG] [historyHTML] - new history html values created [DEBUG] [historyHTML] - done [DEBUG] [historyJSON] - new history json values created [DEBUG] [historyJSON] - done [DEBUG] [umount] - mount activ, umount is started ... [DEBUG] [umount] - umount successfully completed [DEBUG] [umount] - done [EXIT] 0History wird z. B. nicht gepackt, sonst zählt der da die MB, hier nicht:
[DEBUG] [historyDB] - compress from historyDB started ... [DEBUG] [historyDB] - Packed 0MB so far... [DEBUG] [historyDB] - Backup created: /opt/iobroker/backups/historyDB_2
Support us
492
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge