yes. but if i were to restore to it, i will loose all the data since the backup point, right? avoiding another data loss is my next target, i will not waste my time since there is no way to restore the situation as if it never happened. thats why i hadnt asked for this, rather the root-cause.
i remember how it was in the 90’s again. corrupted file systems, indexes etc.
i hadnt turned the unit off during the incident, i hadnt physically moved it, what had happened? the hardware is couple months old: too old for manufacturing mistakes, too new for end-of-life.
i guess i can delete the 1.3 Gig Corrupted file, correct? is there any use left in keeping it?
i wanted to use HA as vanilla as possible, main reason why I had purchased Yellow with high quality SSD, to eliminate as much hardware trouble as possible. but i guess the sqlite3 is not reliable even with high quality SSD drives. which is the reliable way recording should be kept.
Naah…it’s not either of that. Original database is still pretty unstable, no matter how they say that they “did a lot to improve it”…sadly, still not enough. Just a small “glitch” is enough for database to go corrupt and create a new empty one. I’ve had same experience a couple of times a while ago, then i went and install mariadb database inside synology, used that one for a year (or more) without a single drop. When they published that original db has been masively improved i decided to go and try, so i went back to sqlite, only to loose all my data after a week…
Now i have maridadb addon installed and running. way more stable than sqlite.
Try to recover it from corrupted file. There are a lot of tutorials and guide lines online on how to do it.
I didn’t have any problems with sqlitle although I had a lot of restarts, hard reboot, power cut off etc. And system did complained that sqlite wasn’t shutdown cleanly, but I never lost any data.
Maybe this depends on a type of installation, but I’m not sure about that.