Backup lässt sich nicht zurückspielen

[Gryf]

Im direkten Vergleich fiel allerdings auf, dass die alte Karte manchmal Settings bzw. kleinere Änderungen wieder vergessen hat - vermutlich weil dann das Schreiben fehlschlug ... Das ist mir dann aber erst nach dem nächsten Reboot aufgefallen, d.h man hat das garnicht oder erst so spät gemerkt, dass man das nicht mehr wirklich auf dem Radar hatte.

Hier mal "Werbung" für meinen Ansatz, den ich angepasst monit integriert habe, weil mir das auch schon mehrmals passiert war: viewtopic.php?f=65&t=69941&p=682806#p682806

Wie das natürlich so ist, ist es seitdem nicht wieder aufgetreten - genauso, wie es gefühlt nie regnet, wenn man den Schirm mitnimmt

Ciao

Thomas

[jmaus]

Im direkten Vergleich fiel allerdings auf, dass die alte Karte manchmal Settings bzw. kleinere Änderungen wieder vergessen hat - vermutlich weil dann das Schreiben fehlschlug ... Das ist mir dann aber erst nach dem nächsten Reboot aufgefallen, d.h man hat das garnicht oder erst so spät gemerkt, dass man das nicht mehr wirklich auf dem Radar hatte.

Hier mal "Werbung" für meinen Ansatz, den ich angepasst monit integriert habe, weil mir das auch schon mehrmals passiert war: viewtopic.php?f=65&t=69941&p=682806#p682806

Wie das natürlich so ist, ist es seitdem nicht wieder aufgetreten - genauso, wie es gefühlt nie regnet, wenn man den Schirm mitnimmt

Halte es für keine gute Idee solch eine schreib-invasive Methode (regelmäßig das gleiche auf die SD karte zu schreiben) zu nutzen um daraus irgendeinen Health-Status der SD karte abzuleiten. Dies verkürzt nur zwangsläufig die Lebensdauer der SD karte, da Schreiboperationen unter allen umständen minimiert werden sollten. Auch bin ich mir nicht sicher ob deine Vorgehensweise im Ernstfall wirklich Fehler aufzeigen wird. Dadurch das du immer in die gleiche Datei schreibst (auch wenn du dieser vorher löscht) kann es mitunter sein, das die genutzten Blöcke auf der SD Karte die selben sein werden. Auch das ist z.B. kritisch, weil gerade das beschreiben der selben Blöcke auf einer SD Karte vermieden werden sollte. Mit solch einem einfachen Schreib-/Lesetest also einen generellen Health-Status der SD karte abzuleiten halt ich für keine gute Idee und wird auch im Ernstfall sicherlich nicht zum Erfolg führen. Hier erachte ich weiterhin den regelmäßigen BadBlocks Check wie er in RaspberryMatic ja schon länger umgesetzt ist mehr geeignet solche Fälle aufzudecken

[Gryf]

Halte es für keine gute Idee solch eine schreib-invasive Methode (regelmäßig das gleiche auf die SD karte zu schreiben) zu nutzen um daraus irgendeinen Health-Status der SD karte abzuleiten. Dies verkürzt nur zwangsläufig die Lebensdauer der SD karte, da Schreiboperationen unter allen umständen minimiert werden sollten.

Gut, ich selbst halte einmal täglich eine Datei schreiben für kein Problem - wenn eine SD-Karte das nicht mehr packt, ist sie aus meiner Sicht auch nicht mehr brauchbar. Ich werde das weiter nutzen, da es aus meiner Sicht zuverlässig funktioniert (alle bis dahin betroffenen Karten wurden damit eindeutig erkannt, nur ist es halt seitdem auch nicht mehr aufgetreten).

[Baxxy]

Wollten wir nicht mal das /userfs fit für f2fs machen?
Vielleicht würden die SD-Karten damit nicht so schnell "verschleißen".

Und dann habe ich noch im Hinterkopf das wir eventuell den Speicherzyklus der homematic.regadom als Indikator für eine beschreibbare SD-Karte nutzen wollten.

[jmaus]

Und dann habe ich noch im Hinterkopf das wir eventuell den Speicherzyklus der homematic.regadom als Indikator für eine beschreibbare SD-Karte nutzen wollten.

Was meinst du genau? Helf mir mal auf die Sprünge!

[Baxxy]

Ich muss mal gucken ob ich das irgendwo finde.

Es ging darum das wir nicht unnötig (zusätzlich) auf die Karte schreiben wollen.
Die regadom muss aber (zyklisch, bei bestimmten Anlässen) auf die Karte schreiben, so das man hier einen Indikator hätte ob die Karte noch beschreibbar ist.

Grob vereinfacht: prüfe alle xh ob der Zeitstempel der regadom nicht älter als x ist.
Wurde z.B. 12h nichts geschrieben ist was faul.

Edit: war wohl nur eine Idee von mir und kein konkretes Szenario.
https://github.com/jens-maus/RaspberryM ... -897159724

[jmaus]

Grob vereinfacht: prüfe alle xh ob der Zeitstempel der regadom nicht älter als x ist.
Wurde z.B. 12h nichts geschrieben ist was faul.

Edit: war wohl nur eine Idee von mir und kein konkretes Szenario.
https://github.com/jens-maus/RaspberryM ... -897159724

Bin mir ehrlich gesagt nicht so sicher ob ein solch einfacher "Zeitstempeltest" zielführend wäre, denn am Schluss wird ReGaHss sicherlich schon in der Lage sein die Datei zu schreiben. Die Frage ist nur, kommt auch auf der SD karte bzw. dem Medium das Richtige an. Also quasi ein Konsistenzcheck. Und das kann im Grunde nur die ReGaHss selbst liefern bzw. erledigen. Was ich z.B. in der der ReGaHss einbauen könnte, wäre eine Checksumme wie SHA256 über das zu schreibende zu bilden und dann am schluss die regadom datei wieder einzuladen und dann wieder die checksumme zu bilden und diese zu vergleichen. Allerdings wird das nicht nur ziemlich Zeit kosten und auch CPU Zeit aufbrauchen, es ist auch fraglich ob durch verschiedene Caches im Arbeitsspeicher das überhaupt dazu führen würde solche Schreib/Lesefehler aufzudecken. Bin mir da noch nicht ganz so sicher. Daher ja auch dieser BadBlocksCheck weil mir das im Grunde zielführender vorkommt. Auch wird das an verschiedenen Stellen im Internet so auch propagiert. Siehe: https://help.endian.com/hc/it/articles/ ... is-corrupt.

Allerdings wird dort auch erwähnt das man am besten den badblocks check im read-write Modus laufen lassen sollte - was wir allerdings natürlich im laufenden Betrieb nicht machen können. Was ich allerdings machen/überlegen kann ist, dem Recovery System eine zusätzliche Option zu spendieren um solch ein "Medium Check" aktiv durchführen zu lassen. Bei diesem könnte man dann z.B. nicht nur den badblocks check via -n option (non-destructive read/write) durchführen lassen, sondern auch z.B. den speed check durchführen lassen den ich vor einiger Zeit beim firmware update durchführen eingebaut hatte um event. langsam arbeitende Datenträger aufzudecken. Vielleicht wäre das ein zusätzlicher Schritt für etwas mehr sicherheit bzw. mehr Tools zur Datenträgeranalyse.

[iRudi]

Kurze Frage von mir als bekennender "Nicht-Experte" für SD Cards: bei SSDs hilft ja immer eine große Platte, damit immer wieder andere Bereiche beschrieben werden. Mit diesem Gedanken im Hinterkopf hatte ich damals der RaspberryMatic eine 128er SD Card verpasst - wohl wissend, dass ich die nie voll machen will und muss. Aber ist das bei einer SD Card überhaupt so?

Meine (nun defekte) SD Card ist eine SanDisk Extreme microSDXC 128GB - die gerade mal 14 Monate alt war. Das lässt mich vermuten, dass bei SD Cards andere Regeln gelten ...

Ups - Ich sehe gerade, da steht was von 30 Jahren Garantie ... dann werde ich wohl mal versuchen, die Karte zu reklamieren!

[MichaelN]

Nimm beim nächsten mal eine high Endurance. Die sind auf Langlebigkeit getrimmt.

[Baxxy]

Die Frage wäre ja auch, was zum Teufel schreibt deine RM denn alles auf die Karte?
Bei einem normalen System wird doch nur die homematic.regadom (i.d.R. zyklisch) persistiert.