Usually database corruption happened when the write cache is enabled, but node was abruptly stopped, or if you use unstable file system like BTRFS or network filesystems any kind or some configuration of Unraid.
From thousands SNOs only dozens have problems with database corruption, this suggests the non-optimal configuration in these cases.
For example, I did not have a database corruption since start in 2019, but my nodes working on NTFS and ext4, no RAID. NTFS ones has UPS, but ext4 is not (Rpi3). One Windows node is a binary node, two others - docker for Windows (so even worse, these two uses a network filesystem (p9) to access disks).
So, depends on the setup.
This is not considered as a normal situation, it requires investigation, because missing databases only smallest of the problems in such case.
Dumb automation doesn’t help, it will just hide the problem. And we likely will have posts - “I found a bug - my stat suddenly disappeared!”
Again, it’s not a common and normal situation. I against such automatization, which hides problems.
Unlikely. Usually you also have a data corruption in other places, just not discovered yet. Audits did not check the entire dataset, they are random for random parts of pieces, they are used only to determine, can the satellite trust your node or not, not to check the entire data integrity. If you have corruption, it will be catched eventually and your node could be disqualified.
This suggests the slow disk subsystem or other hardware issues, when the process cannot be stopped normally even after 300 seconds of timeout, if your OS respects this timeout at all.
Yep, you may read the Unraid forum for SQLite corruption for any application. So, it depends. And not always on the application, it also the underlying setup. Why I did not have an SQLite corruption for the last 4 years? And remained thousands SNOs?
then you probably should place databases back to the dataset, if it’s more reliable, than having them on SSD.
The only known feature request is