@mcm1957 sagte:
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.
Soweit habe ich noch nicht gedacht - es ist (leider) für jeden nachzuvollziehen wie das Backup gestört werden kann ohne das der ioBroker selber abstürzt:
Man nehme:
einen Datenpunkt (z.Bsp. 0_userdata.0.testing.testing), typ String
dieses Skript
setState('0_userdata.0.testing.testing',`{"bla":"tes${String.fromCharCode(parseInt('2028', 16))}ting"}`);
Nebenbei: das ich da ein JSON als String rein schreibe dient dazu, den Fehler zu visualisieren. Der JSON Editor zeigt das falsche Zeichen sichtbar an - wenn einfach nur das Script
setState('0_userdata.0.testing.testing',`tes${String.fromCharCode(parseInt('2028', 16))}ting`);
genutzt wird tritt der Fehler auch auf - ist aber deutlich schwerer zu erkennen:
[image: Screenshot 2026-09-14 at 19.55.19.png]
vs
[image: Screenshot 2026-09-14 at 19.56.18.png]
Nach Ausführung des Skriptes führt der ioBroker (bei mir, mit redis als state/objekt Datenbank) das Backup nicht mehr aus.
Alleine durch schreiben eines sauberen Wertes in den Datenpunkt kann das korrigiert werden - dann gehen auch wieder Backups.
disclaimer: Ich hab das nicht auf einem System mit JSONL als Objekt/State DB getestet. Es ist denkbar das in diesem Fall der ioBroker nicht startet wenn er neustarten soll bevor der Fehler korrigiert wurde weil er die ObjektDB nicht einlesen kann. Testen auf eigenes Risiko
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.
Bei mir sind die ungültigen Daten vom Adapter iCloud geschrieben worden. Die werden auch restauriert wenn der Adapter neu synchronisiert. Daher habe ich die Information erst einmal an den Autor des Adapters weiter gegeben.
In wieweit da der JS-Controller beim schreiben der JSONL Datei das absichern kann/soll kann ich erst einmal nicht bewerten.
