Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[paul53]

@homoran sagte: liegt an den unmengen Daten, die teilweise im Millisekundentakt geschrieben werden.

Welche Daten werden im Millisekundentakt geschrieben?

[Heimweh]

Naja ehrlicherweise muss man sagen dass nicht alle Stromausfälle die Schuld des Netzbetreibers sind bzw. waren... - klar das kommt auch vor aber es war auch mal ein FI der ausgelöst hatte / mal die Sicherung geflogen und einmal war ich auch selber dran schuld - vergessen alle VMs runterzufahren vor ausstecken.... Das kommt schonmal vor wenn man nebenher renoviert.

Naja ok. Ich werde das Thema USV mal angehen. Wenn dieses Verhalten normal ist dann muss ich diesen Weg gehen.... Vielen lieben Dank Euch!

[Homoran]

@paul53 sagte in das leidige Thema "Stromausfall":

Welche Daten werden im Millisekundentakt geschrieben?

das bezog sich auf die Datenpunkte in Summe
(natürlich nicht die Karte)

[paul53]

@homoran sagte: natürlich nicht die Karte

Die Schreibfrequenz auf den Massenspeicher ist aber entscheidend für die Wahrscheinlichkeit, dass ein Stromausfall zu einem defekten Filesystem führt.
In der Datei iobroker-data/iobroker.json kann z.B. die Schreibfrequenz für die states.json vorgegeben werden: "writeFileInterval": 300000 (5 Minuten).

@heimweh sagte in das leidige Thema "Stromausfall":

Ich werde das Thema USV mal angehen.

Sehr vernünftig!

[BananaJoe]

Also mein ioBroker läuft in einer VM unter VMWare, Ubuntu 20.04 LTS. Gesichert wird das ganze per VEEAM, also per Snapshot im laufenden Betrieb.

Für eine VM ist das nach einen Restore wie nach einem ein Stromausfall. Und da war noch nie was kaputt.
Bei einem Snapshot wird der VM über die VMware-Tools bescheid gesagt das ein Snapshot stattfindet. Da versucht das Betriebssystem dann noch mal eben alle Caches auf Platte zu leeren und mal einen Moment nicht zuschreiben.
Da kann man dann auch eigene Scripte einbinden, ich unterbinde bei Snapshoterstellung auch alle Schreibzugriffe des MySQL und leere dessen Schreibcache. Das gilt nur für die paar Sekunden der Erstellung.

Ob Proxmox da ähnlich fährt - keine Ahnung.

Anderes herum: Wann geht denn was "kaputt"? Kaputt geht immer dann etwas wenn er beim schreiben von Daten auf die Festplatte unterbrochen wird.

Jetzt weis ich nicht genau was der ioBroker so alles schreibt, aber das schreiben müsste dann hart unterbrochen worden sein. Wenn es die VIS View ist so müsste er die JSON-Datei, eine schnöde Textdatei, ja in dem Moment am Schreiben gehabt haben. Ich würde nun denken die Datei ist statisch und wird nur geändert wenn man im Editor im Gange ist, also eigentlich ja praktisch nie.

Wenn man das System neu startet so wird es ja heruntergefahren. Also alle Dienste beendet. In dem Fall sollte ioBroker ja noch alles einmal in Ruhe weg schreiben können was er so schreiben will - oder geht da laut Logs etwas schief?

Also eigentlich kann da gar nichts kaputt gehen oder es ist ein anderes Problem.

[ente34]

@homoran sagte in das leidige Thema "Stromausfall":

Wieso um alles in der Welt haben so viele User dauernd Stromausfall?

Weil wir auf dem Land leben.
Ich hatte 2021 fünf Stromausfälle, vier im Januar (Schneebruch) und einer im Juni (Starkregen)

Allerdings eine SSD am Raspi und bisher noch keine Ausfälle.

[Homoran]

@bananajoe sagte in das leidige Thema "Stromausfall":

Wann geht denn was "kaputt"? Kaputt geht immer dann etwas wenn er beim schreiben von Daten auf die Festplatte unterbrochen wird.
Jetzt weis ich nicht genau was der ioBroker so alles schreibt, aber das schreiben müsste dann hart unterbrochen worden sein

soweit korrekt, es geht aber meist um die objects.json in der alle Datenpunkte und Konfigurationen gespeichert werden.
Die wird häufiger geschrieben.

Auch wenn @paul53 eben gezeigt hat wie man diese Schreibvorgänge auf 5 Minuten einstellen kann, kenne ich im MOment den Standardwert nicht. (oder ist 5 Minuten der Standard?

Bei Anhebung dieses Wertes auf x Minuten muss man natürlich bedenken, dass im schlimmsten Fall alles weg ist, was in den letzten x Minuten passiert ist

[Heimweh]

@homoran genau so ist es - es ist immer die objects.json und die Frage mit dem default Wert hatte ich jetzt auch im Kopf

[Homoran]

@heimweh sagte in das leidige Thema "Stromausfall":

@homoran genau diese Frage hatte ich auch im Kopf!?

Jetzt habe ich mich schnell für dich an einen PC gesetzt und nachgesehen:

Ich finde den Eintrag "writeFileInterval": 300000 gar nicht.

@paul53 der müsste für die Objects doch unter "objects: { stehen?
oder muss der grundsätzlich erst angelegt werden?

Wenn ja, bleibt die Frage wie hoch die Schreibfrequenz standardmäßig ist

[AlCalzone]

Ggf. könnte für solche fälle die JSONL-Datenbankvariante interessant sein, die voraussichtlich in Controller v4 Standard wird:
https://forum.iobroker.net/post/732513

Die sollte prinzipbedingt (inkrementelles Schreiben, appendonly) einen Totalverlust verhindern und dabei auch noch die SD-Karte schonen.

[paul53]

@homoran sagte: ist 5 Minuten der Standard?

Soweit ich mich erinnere, sind 30 s der Standardwert.

[paul53]

@homoran sagte: oder muss der grundsätzlich erst angelegt werden?

Ich denke: Ja. Unter "states":

  "states": {
    "type": "file",
    "typeComment": "Possible values: 'file' - [port 9000], 'redis' - [port 6379].",
    "host": "127.0.0.1",
    "port": 9000,
    "maxQueue": 1000,
    "writeFileInterval": 300000,
    "options": {
      "auth_pass": null,
      "retry_max_delay": 5000
    },

Die Datei objects.json sollte ohnehin nicht häufig geschrieben werden, wenn man davon ausgeht, dass die Objekte quasi statisch sind (sein sollen).

[OliverIO]

@heimweh

Das Risiko der Beschädigung einer Datei oder gar des ganzen System bei Strom weg ist im speziellen bei sd Karten gegeben, da diese im Gegensatz zu ssd Festplatten keine eigenen kondensatoren haben die noch genug Strom haben um zumindest den Cache noch zu schreiben.
Da bei sd/ssd immer größere Blocks geschrieben werden, die auch mal größer wie eine Datei sein kann ist, wenn das nicht abgeschlossen werden kann, die Datei oder das ganze Datei System hinüber. Manchmal kann das repariert werden aber nicht immer.
Wenn du eine sd Karte gegen eine ssd tauschst dann minimierst du das Risiko noch weiter.

Ganz ausschließen kann man das Risiko aber bei keinem Speichermedium. Mit einer usv hat man zumindest aber auch noch genügend Strom um eine ganze applikation und das Betriebssystem ordentlich herunterzufahren.

[Homoran]

@paul53 sagte:

Die Datei objects.json sollte ohnehin nicht häufig geschrieben werden

aber bei allen Fällen, die @Thomas-Braun und ich in der letzten Zeit in den Fingern hatten war nur (noch) die Objects.db hin.

[paul53]

@homoran sagte in das leidige Thema "Stromausfall":

war nur (noch) die Objects.db hin.

Dann sollte auch unter "objects" ein ausreichend großer Wert ergänzt werden.

  "objects": {
    "type": "file",
    "typeComment": "Possible values: 'file' - [port 9001], redis - [port 6379], couch - [port 5984].",
    "host": "127.0.0.1",
    "port": 9001,
    "user": "",
    "pass": "",
    "noFileCache": false,
    "connectTimeout": 2000,
    "writeFileInterval": 600000,
    "backup": {

Anschließend ioBroker neu starten.

[Homoran]

@paul53 Danke!

Vielleicht liegt es aber auch an der Größe der objects.json, die selbst im gepackten Zustand noch gerne im (auch höheren) MB-Bereich liegt

[paul53]

@homoran sagte: Vielleicht liegt es aber auch an der Größe der objects.json

Je größer die Datei, desto seltener sollte sie geschrieben werden.

[OliverIO]

@paul53
wenn sie zu groß wird, sollte man auf redis wechseln

[paul53]

@oliverio sagte: sollte man auf redis wechseln

Redis schreibt in der Standardeinstellung auch alle 5 Minuten.

[OliverIO]

@paul53
ja aber iobroker schreibt ja plumb einfach eine komplette datei was bei größerer Datei dann immer länger dauert.

redis kann über direkte datei-operationen nur bestimmte Anteile einer datei anpassen (verwendet die datei sozusagen als eigenes dateisystem) oder es hängt einfach immer nur an und reorganisiert in regelmäßigen abständen dann die daten, wie es datenbanken oft machen. die genaue strategie kenn ich nicht.