Kein Backup nach Systemupdate (gelöst)
-
Bitte ausfüllen:
- Adaptername: backitup / JS-Controller
- Adapterversion: 4.0.3
- js-controller Version: 7.2.2
- Admin Version: 8.0.3
- Hardwaresystem: Pi5
- Arbeitsspeicher: 8xGB
- Festplattenart: SSD
- Betriebssystem: Debian 12
- Nodejs-Version: 24.20.0
Seit ich auf die oben angegebene Version aktualisert habe bekomme ich kein Backup vom ioBroker hin. Der Fehler den ich bekomme ist immer:
stormy@stormbroker:/opt/iobroker $ iob backup host.raspberrypi 11163 objects saved host.raspberrypi 9179 states saved host.raspberrypi Validating backup ... host.raspberrypi "config.json" is valid host.raspberrypi "objects.jsonl" exists host.raspberrypi "states.jsonl" exists host.raspberrypi Backup not created: The "objects.jsonl" file is corrupted: Unterminated string in JSON at position 32144 (line 1 column 32145) Cannot create backup: The "objects.jsonl" file is corrupted: Unterminated string in JSON at position 32144 (line 1 column 32145)Dabei nutzt das System Redis für die States und Objects.
Intial hatte ich noch Dateien aus Januar 25 im Verzeichnis
/opt/iobroker/iobroker-dataliegen. Ich habe mir diese Dateien herunter geladen um zu prüfen das sie saubere json Dateien sind - sie sind es.
Da die Dateien aus Januar 25 sind bin ich davon ausgegangen das sie nicht mehr aktiv benutzt werden. Daher habe ich den ioBroker angehalten, die Dateien entfernt (verschoben in ein Unterverzeichnisremoved_jsonlund umbenannt aufoldstates.jsonundoldobjects.json.stormy@stormbroker:~ $ ls -al /opt/iobroker/iobroker-data/ total 84 drwxrwxr-x+ 15 iobroker iobroker 4096 Sep 11 20:19 . drwxrwxr-x+ 6 iobroker iobroker 4096 Sep 11 19:35 .. drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 11 20:30 backitup drwxrwxr-x+ 2 iobroker iobroker 4096 Jan 25 2025 backup-objects drwxrwxr-x+ 4 iobroker iobroker 4096 Jan 25 2025 files drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 10 20:48 icloud.0 -rw-rwxr--+ 1 iobroker iobroker 3674 Jan 25 2025 iobroker.json -rw-rwxr--+ 1 iobroker iobroker 7479 Jan 25 2025 iobroker.json.bak drwxrwxr-x+ 2 iobroker iobroker 4096 Dec 4 2025 matter.0 drwxrwxr-x+ 5 iobroker iobroker 4096 Feb 1 2025 node-red -rw-rwxr--+ 1 iobroker iobroker 9140 Sep 13 20:11 notifications.json drwxrwxr-x+ 2 stormy stormy 4096 Sep 11 20:19 removed_jsonl drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 13 20:12 yahka.0.hapdata drwxrwxr-x+ 6 iobroker iobroker 4096 Sep 13 20:12 zigbee_0 drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 25 2025 zigbee_1 drwxrwxr-x+ 2 iobroker iobroker 4096 Jul 26 11:10 zigbee_10 drwxrwxr-x+ 2 iobroker iobroker 4096 Feb 7 2025 zigbee_6 drwxrwxr-x+ 2 iobroker iobroker 4096 Mar 24 2025 zigbee_8Trotzdem bleibt die oben angegebene Fehlermeldung erhalten.
Was kann ich noch tun um die Fehlerursache heraus zu finden ?
Lt. Diagnostic gibt es keine relevanten Auffälligkeiten. (Das das System noch im oldstable ist sehe ich nicht als relevant an. Jeden Kommentar das erst zu lösen werde ich also einfach ignorieren.)
iob Diag im Spoiler.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
Bitte ausfüllen:
- Adaptername: backitup / JS-Controller
- Adapterversion: 4.0.3
- js-controller Version: 7.2.2
- Admin Version: 8.0.3
- Hardwaresystem: Pi5
- Arbeitsspeicher: 8xGB
- Festplattenart: SSD
- Betriebssystem: Debian 12
- Nodejs-Version: 24.20.0
Seit ich auf die oben angegebene Version aktualisert habe bekomme ich kein Backup vom ioBroker hin. Der Fehler den ich bekomme ist immer:
stormy@stormbroker:/opt/iobroker $ iob backup host.raspberrypi 11163 objects saved host.raspberrypi 9179 states saved host.raspberrypi Validating backup ... host.raspberrypi "config.json" is valid host.raspberrypi "objects.jsonl" exists host.raspberrypi "states.jsonl" exists host.raspberrypi Backup not created: The "objects.jsonl" file is corrupted: Unterminated string in JSON at position 32144 (line 1 column 32145) Cannot create backup: The "objects.jsonl" file is corrupted: Unterminated string in JSON at position 32144 (line 1 column 32145)Dabei nutzt das System Redis für die States und Objects.
Intial hatte ich noch Dateien aus Januar 25 im Verzeichnis
/opt/iobroker/iobroker-dataliegen. Ich habe mir diese Dateien herunter geladen um zu prüfen das sie saubere json Dateien sind - sie sind es.
Da die Dateien aus Januar 25 sind bin ich davon ausgegangen das sie nicht mehr aktiv benutzt werden. Daher habe ich den ioBroker angehalten, die Dateien entfernt (verschoben in ein Unterverzeichnisremoved_jsonlund umbenannt aufoldstates.jsonundoldobjects.json.stormy@stormbroker:~ $ ls -al /opt/iobroker/iobroker-data/ total 84 drwxrwxr-x+ 15 iobroker iobroker 4096 Sep 11 20:19 . drwxrwxr-x+ 6 iobroker iobroker 4096 Sep 11 19:35 .. drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 11 20:30 backitup drwxrwxr-x+ 2 iobroker iobroker 4096 Jan 25 2025 backup-objects drwxrwxr-x+ 4 iobroker iobroker 4096 Jan 25 2025 files drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 10 20:48 icloud.0 -rw-rwxr--+ 1 iobroker iobroker 3674 Jan 25 2025 iobroker.json -rw-rwxr--+ 1 iobroker iobroker 7479 Jan 25 2025 iobroker.json.bak drwxrwxr-x+ 2 iobroker iobroker 4096 Dec 4 2025 matter.0 drwxrwxr-x+ 5 iobroker iobroker 4096 Feb 1 2025 node-red -rw-rwxr--+ 1 iobroker iobroker 9140 Sep 13 20:11 notifications.json drwxrwxr-x+ 2 stormy stormy 4096 Sep 11 20:19 removed_jsonl drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 13 20:12 yahka.0.hapdata drwxrwxr-x+ 6 iobroker iobroker 4096 Sep 13 20:12 zigbee_0 drwxrwxr-x+ 2 iobroker iobroker 4096 Sep 25 2025 zigbee_1 drwxrwxr-x+ 2 iobroker iobroker 4096 Jul 26 11:10 zigbee_10 drwxrwxr-x+ 2 iobroker iobroker 4096 Feb 7 2025 zigbee_6 drwxrwxr-x+ 2 iobroker iobroker 4096 Mar 24 2025 zigbee_8Trotzdem bleibt die oben angegebene Fehlermeldung erhalten.
Was kann ich noch tun um die Fehlerursache heraus zu finden ?
Lt. Diagnostic gibt es keine relevanten Auffälligkeiten. (Das das System noch im oldstable ist sehe ich nicht als relevant an. Jeden Kommentar das erst zu lösen werde ich also einfach ignorieren.)
iob Diag im Spoiler.
A.
-
EDIT= dummfug
-
Könnte es ein Bild in den mqtt Objekten sein?
Proxmox 9 HA-Cluster mit 3x HP prodesk 400 G6 i5
ioBroker Backup Analyzer -
Könnte es ein Bild in den mqtt Objekten sein?
-
Hmm, ich hatte die Meldung auch vor kurzem und ich hab auch Redis. Das Backup konnte nicht erstellt werden und bei mir lag es ein an einem Objekt was von einem Bild gekommen ist. Beim erstellen des Backups wird diese Datei objects.jsonl ja angelegt.
edit
Du musst herausfinden welches Objekt diesen Fehler verursacht, löschen und dann läuft das Backup durch. -
Die Meldung kommt nicht von Backitup, sondern vom js-controller. Backitup ruft nur iobroker backup auf, und der macht Folgendes:
- Er legt den Ordner /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/ an.
- Er holt alle Objekte aus der laufenden Datenbank und schreibt jedes als eine Zeile in eine neue objects.jsonl in diesem Ordner. Dasselbe passiert mit den States.
- Er liest beide Dateien zeilenweise zurück und prüft jede Zeile mit JSON.parse. Darum bezieht sich „line 1 column 32145" auf eine einzelne Zeile, nicht auf die ganze Datei.
- Schlägt die Prüfung fehl, löscht er den tmp-Ordner sofort wieder. Deshalb findet man die geprüfte Datei hinterher nicht mehr.
Die objects.jsonl in iobroker-data ist also nicht die geprüfte Datei. Selbst wenn dort eine Zeile defekt wäre, überspringt der js-controller sie beim Start, und der Export aus dem Speicher wäre trotzdem gültig.
Was die Meldung bedeutet
Der Export erzeugt nie kaputtes JSON. Wenn die zurückgelesene Zeile nach 32 KB mitten in einem String endet, wurde sie beim Schreiben abgeschnitten. Typische Ursachen: Platte voll oder Schreibfehler im Dateisystem, etwa eine sterbende SD-Karte. Erster Blick:
df -h /opt/iobroker df -i /opt/iobroker dmesg | grep -iE "i/o error|ext4|mmc" | tailDann iobroker backup einmal von Hand in der Konsole starten. Dort sieht man die komplette Ausgabe, die Backitup nur im Debug-Log zeigt. Interessant sind die Zeilen „Cannot get objects: …" oder „Cannot get states: …" direkt vor „Validating backup …".
Die betroffene Zeile finden
Weil der tmp-Ordner gelöscht wird, muss man die Datei während des Laufs wegkopieren. Im ersten Terminal:
while true; do cp /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/objects.jsonl /tmp/objects_dump.jsonl 2>/dev/null; cp /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/states.jsonl /tmp/states_dump.jsonl 2>/dev/null; sleep 0.2; doneIm zweiten Terminal:
iobroker backupNach dem Fehler das erste Terminal mit Strg+C beenden. Der folgende Einzeiler liest die Kopie genauso wie der js-controller und nennt Zeilennummer, Objekt-ID, Zeilenlänge und die 120 Zeichen vor der gemeldeten Position:
node -e 'const {open}=require("fs/promises");(async()=>{const fd=await open(process.argv[1]);let n=0;for await(const line of fd.readLines()){n++;try{JSON.parse(line)}catch(e){const m=line.match(/"_?id":"([^"]+)"/);const p=+((e.message.match(/position (\d+)/)||[0,line.length])[1]);console.log("Zeile "+n+": "+(m?m[1]:"ID unlesbar")+" | Laenge "+line.length+" | "+e.message);console.log("..."+line.slice(Math.max(0,p-120),p)+" <<< Position "+p)}}})()' /tmp/objects_dump.jsonlFür die States denselben Aufruf mit /tmp/states_dump.jsonl am Ende.
Einordnung des Ergebnisses
- Ist die gemeldete Zeile die letzte in der Kopie, wurde der Export mittendrin abgebrochen. Dann zuerst Platz schaffen, zum Beispiel alte Backups in /opt/iobroker/backups und im Backitup-Zielordner löschen, und den Lauf wiederholen.
- Steht die Zeile mitten in der Datei, ist die Objekt-ID der Ausgangspunkt. Das Objekt im Admin unter „Objekte" ansehen und prüfen, welcher Adapter es angelegt hat.
Zur Kontrolle der Live-Dateien reicht ein Blick auf die letzten 100 Zeichen. Endet die Ausgabe mit }$, ist die letzte Zeile vollständig, fehlt das $, ist sie abgeschnitten:
tail -c 100 /opt/iobroker/iobroker-data/objects.jsonl | cat -A tail -c 100 /opt/iobroker/iobroker-data/states.jsonl | cat -AProxmox 9 HA-Cluster mit 3x HP prodesk 400 G6 i5
ioBroker Backup Analyzer -
Die Meldung kommt nicht von Backitup, sondern vom js-controller. Backitup ruft nur iobroker backup auf, und der macht Folgendes:
- Er legt den Ordner /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/ an.
- Er holt alle Objekte aus der laufenden Datenbank und schreibt jedes als eine Zeile in eine neue objects.jsonl in diesem Ordner. Dasselbe passiert mit den States.
- Er liest beide Dateien zeilenweise zurück und prüft jede Zeile mit JSON.parse. Darum bezieht sich „line 1 column 32145" auf eine einzelne Zeile, nicht auf die ganze Datei.
- Schlägt die Prüfung fehl, löscht er den tmp-Ordner sofort wieder. Deshalb findet man die geprüfte Datei hinterher nicht mehr.
Die objects.jsonl in iobroker-data ist also nicht die geprüfte Datei. Selbst wenn dort eine Zeile defekt wäre, überspringt der js-controller sie beim Start, und der Export aus dem Speicher wäre trotzdem gültig.
Was die Meldung bedeutet
Der Export erzeugt nie kaputtes JSON. Wenn die zurückgelesene Zeile nach 32 KB mitten in einem String endet, wurde sie beim Schreiben abgeschnitten. Typische Ursachen: Platte voll oder Schreibfehler im Dateisystem, etwa eine sterbende SD-Karte. Erster Blick:
df -h /opt/iobroker df -i /opt/iobroker dmesg | grep -iE "i/o error|ext4|mmc" | tailDann iobroker backup einmal von Hand in der Konsole starten. Dort sieht man die komplette Ausgabe, die Backitup nur im Debug-Log zeigt. Interessant sind die Zeilen „Cannot get objects: …" oder „Cannot get states: …" direkt vor „Validating backup …".
Die betroffene Zeile finden
Weil der tmp-Ordner gelöscht wird, muss man die Datei während des Laufs wegkopieren. Im ersten Terminal:
while true; do cp /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/objects.jsonl /tmp/objects_dump.jsonl 2>/dev/null; cp /opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/states.jsonl /tmp/states_dump.jsonl 2>/dev/null; sleep 0.2; doneIm zweiten Terminal:
iobroker backupNach dem Fehler das erste Terminal mit Strg+C beenden. Der folgende Einzeiler liest die Kopie genauso wie der js-controller und nennt Zeilennummer, Objekt-ID, Zeilenlänge und die 120 Zeichen vor der gemeldeten Position:
node -e 'const {open}=require("fs/promises");(async()=>{const fd=await open(process.argv[1]);let n=0;for await(const line of fd.readLines()){n++;try{JSON.parse(line)}catch(e){const m=line.match(/"_?id":"([^"]+)"/);const p=+((e.message.match(/position (\d+)/)||[0,line.length])[1]);console.log("Zeile "+n+": "+(m?m[1]:"ID unlesbar")+" | Laenge "+line.length+" | "+e.message);console.log("..."+line.slice(Math.max(0,p-120),p)+" <<< Position "+p)}}})()' /tmp/objects_dump.jsonlFür die States denselben Aufruf mit /tmp/states_dump.jsonl am Ende.
Einordnung des Ergebnisses
- Ist die gemeldete Zeile die letzte in der Kopie, wurde der Export mittendrin abgebrochen. Dann zuerst Platz schaffen, zum Beispiel alte Backups in /opt/iobroker/backups und im Backitup-Zielordner löschen, und den Lauf wiederholen.
- Steht die Zeile mitten in der Datei, ist die Objekt-ID der Ausgangspunkt. Das Objekt im Admin unter „Objekte" ansehen und prüfen, welcher Adapter es angelegt hat.
Zur Kontrolle der Live-Dateien reicht ein Blick auf die letzten 100 Zeichen. Endet die Ausgabe mit }$, ist die letzte Zeile vollständig, fehlt das $, ist sie abgeschnitten:
tail -c 100 /opt/iobroker/iobroker-data/objects.jsonl | cat -A tail -c 100 /opt/iobroker/iobroker-data/states.jsonl | cat -A@Shadowhunter23
Vielen Dank für die Details. Ich hab beides mal gemacht:State des Systems scheint gut (ich hab auch mal alle nvme meldungen aus dmesg mitgegeben:
stormy@stormbroker:~ $ dmesg | grep -iE "i/o error|ext4|mmc|nvme" | tail [ 2.176827] nvme nvme0: Ignoring bogus Namespace Identifiers [ 2.185052] nvme0n1: p1 p2 [ 2.664564] sdhci-brcmstb 1000fff000.mmc: Got CD GPIO [ 2.664644] mmc1: CQHCI version 5.10 [ 2.669737] mmc0: CQHCI version 5.10 [ 2.714064] mmc0: SDHCI controller on 1000fff000.mmc [1000fff000.mmc] using ADMA 64-bit [ 2.863102] mmc1: SDHCI controller on 1001100000.mmc [1001100000.mmc] using ADMA 64-bit [ 2.903687] mmc1: new ultra high speed DDR50 SDIO card at address 0001 [ 3.590822] EXT4-fs (nvme0n1p2): mounted filesystem ce208fd3-38a8-424a-87a2-cd44114eb820 ro with ordered data mode. Quota mode: none. [ 4.448618] EXT4-fs (nvme0n1p2): re-mounted ce208fd3-38a8-424a-87a2-cd44114eb820 r/w. stormy@stormbroker:~ $Vollständig ist die Datei schon - der Fehler kommt aus einem State - da muss ich schauen wo der genau her kommt.
Allerdings sehe ich da trotzdem einen Bug im JS-Controller - beim Fehler muss die Datei entweder erhalten bleiben, oder eine bessere Meldung gegeben werden - sonst kommt man da nie drauf.
da mach ich morgen einen Bug Report im JS-Controller.
Nochmal vielen Dank.
-
Wie gesagt bei mir war es ein Bild unter mqtt welches den file is corrupted erzeugt hat. Nach dem löschen des Objektes lief das Backup wieder fehlerfrei durch.
Proxmox 9 HA-Cluster mit 3x HP prodesk 400 G6 i5
ioBroker Backup Analyzer -
Wie gesagt bei mir war es ein Bild unter mqtt welches den file is corrupted erzeugt hat. Nach dem löschen des Objektes lief das Backup wieder fehlerfrei durch.
@Shadowhunter23 Bei mir sind es Einträge im
nativedie aus dem icloud2 Adapter kommen. Das zu finden ist selbst mit deinen Code-Schnipseln (nochmal danke dafür) nicht einfach.Ich hab einen Issue am JS-Controller zum Thema löschen der Daten auch wenn Fehler beim Parsen auftreten aufgemacht. https://github.com/ioBroker/ioBroker.js-controller/issues/3484
A.
-
Ich frag mich nur warum irgendwelche Einträge im native das Backup crashen dürfen. Das sieht eigentlich nach eine Fehler im Backupkonzept oder im adpater-core aus. Solange ich etwas (egal was) mit den Systemroutinen in meine Objekte schreiben kann darf m.E. das Backup nicht daran scheitern sonern muss das 1:1 sichern und restaurieren.
Ev. wäre da ein zweites Issue mit der Forderung nach Backup muss alles sichern oder Schreiben ungültiger Daten muss verhindert werden angebracht. Wenn du das noch infos hast welcher Art die ungültigen Daten waren schreib das ggF.
P.S. Ich gehe davon aus, dass die ungültigen Daten NICHT durch manuelle Aktionen oder Dehle im Datei / Datenbanksystem oder Crashes entstanden sind.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
498
Online33.1k
Benutzende83.8k
Themen1.4m
Beiträge