The solution to DB corruption

When we state a database is corrupt, it does not always mean the level db is corrupt.

It can mean:

  1. the level db has reported corruption. LevelDB is notorious for corruption, but only in 2 situations:
    1a) the bits of the level db indexes have been manipulated by underlying hardware, or:
    1b) parts of the level db are missing. This can sometimes happen due to antivirus software, or an operating system that has been shutdown improperly and decides to kill the file that was not properly closed out.

  2. the leveldb read fine, but when we read the records, the data inside the record could not be parsed as valid. This always points to hardware errors. This is the more common of the two cases, and it makes sense since the content of the db is much larger than the overhead of the DB structure itself.

We also check both of these types of corruptions statistically, and as a %, they are constant with the growth of our userbase and match the failure rates we see of SSDs in the wild. The SSD failure rates are based on the tens of thousands of Nucleus units we have sold as well as industry numbers out there (which are pretty closely matching).

I know it’s going around these forums that level db is easily corruptable, but that’s just people trying to make sense of something they don’t know the full picture about.

Our advice is to have a backup of your Roon database.

Unfortunately, we had a shameful fault here, in that the backup functionality backed up the database files and did not do a full analysis of the db’s content before backing up. Therefore, it would backup any databases that were “corrupt”. This was resolved in build 880, in that it catches the corruptness before backing up.

9 Likes