The solution to DB corruption

Hello there

I understand there is no solution. I see a lot of posts about upset customers losing everything.

So far, to avoid the risk of this issue, would you say that it users should not update Roon?


The corruption is there if you update or not, it will likely eventually failn.if it is corrupt. It’s not the new version corrupting it. It’s just flagging that it is now. Also you won’t be able to avoid updating forever. It’s not a great situation for anyone to be in and one Roon should not have let happen in the first place. Why have a backup system that doesn’t have any integrity checks or inbuilt checks to warn of this. So for us long timers it’s a case of fixing the gate after the Horse has bolded. Not sure how widespread this is over the entire user base I guess we won’t ever know.


This should be exactly zero%. in my view. Roon should have provided a repair tool for us to use. The LevelDB tools @killdozer linked to Database issue after updating - #4 has been around for some years so Roon could (should) have done something about it.


Here’s a question/test I’d like to know the answer to. If you have a DB backup that 880 feels is corrupt, can it be restored using the previous version still? Put another way is the DB unusable OR is 880 fussier.

Regarding backups, if you don’t actually test a restore from one then it’s not worth the name. Lost count of the times I’ve gone to support, at various orgs, for recovery from backup to find that something’s not working properly and the backups are hosed.

Edit: If you work somewhere and care about backups it’s worth requesting a recovery every 3 months or so, just to see if you can when you need to.


I agree with that it should be zero.

1 Like

Definitely. I’m consistently pessimistic when it comes to almost everything in life and it’s strangely liberating. It’s not that I think that things will go wrong, it’s that I think that things might go wrong. I therefore ensure that I have potential solutions in place for when this happens (after all, isn’t this why we ensure our homes and contents?).

I periodically test my Roon backups by restoring the most recent one. I also backup my backups on my Google Drive. This might sound like a lot of effort, but it comes naturally to a liberated pessimist like me.


Do you put them into an archive format, e.g. a zip for this? The little bitty file thing in the Roon backups is a nightmare to deal with if you don’t.

1 Like

I haven’t done, but that sounds like a much better idea. Thanks

1 Like

I don’t do that, I just back up the entire folder to oneDrive. Might see if there is a way for hybrid backup on my Nas to automatically zip it up.

I got there via using Dropbox for a restore, it takes forever and it was easier to handle the large single files, although creating them takes a while. If your system works for you don’t let me put you off :slight_smile:

That’s what I’ve been doing. I set up a sync with my Google Drive without zipping.

Thanks for your messages.

I’m also puzzled. What’s the point of having a DB, a backup but no tools to avoid corruption? Is this an oversight from Roon? Maybe it’s just to cut costs or a lack of something?

What really shocks me here is the communication. We have Kevin sharing a message without a nice output. It feels that he is left alone and he doesn’t have the support from Roon, I do sympathise with him. Instead, I would have expected a more positive message with a commercial gesture like a discount for all people impacted.

On top of that, it’s the premium price of the solution. It’s all about the experience that Roon advertises on every pages but this kind of updates is the best way to destroy trust and reputation. I see a pattern here as it is not the first time users are experiencing issues with new updates.

Now, I am afraid of updating and I’m told there is nothing I can do. Meanwhile, I see new features that I don’t believe address the majority of customers and yes I am well aware there is no more feature request at Roon but feature suggestions and it is

Instead, a word of sympathy from Roon, acknowledgement & ownership and some information on whether Roon is looking for a workaround would


How and why Roon chose LevelDB is an interesting question. Costs aren’t an issue, there are plenty of open-source and reliable database implementations. These cover plenty of use cases and types, e.g. RDBMS, “no SQL”, triple stores, and on. With LevelDB Roon have gone for a performant key/value store, little more than a phone directory at heart (the simplest analogy). So it’s fast and simple, the downsides are no model/queries, single process (but multiple threaded?) access, no client-server deployment, and a rep for being corruptible. There are more resilient solutions, e.g. most RDBMSs, but they will have their own downsides, possibly performance among them.

On another note. While it’s not a solution to corruption a good backup strategy helps. Rather than have a single schedule, multiple schedules/locations and strategic retention can work well. Something like:

  • Every day and keep 3
  • Every 2 days and keep 3
  • Every week and keep 3
  • Every month and keep 5
  • Every 6 months and keep 2
  • Every year and keep 5

This keeps plenty of recent backups in different places and you retain a long, sparse tail should the worst happen.


That’s interesting. LevelDB doesn’t offer checksum or anti corruption mechanism? I mean I’m not from the tech world but when I hear about DB, it’s usually MySQL, Azure SQL or Cosmos and their equivalents from Oracle or AWS.

From Wikipedia:

LevelDB has history of database corruption bugs.[15][16][17][18][19][20] A study from 2014 has found that, on older (non-checksummed) file systems, the database could become corrupted after a crash or power failure.[21]


LevelDB, despite the name, is not actually a database, as the term is usually understood. It’s a fast key-value store, with persistence features that are kind of a side-effect of its design, which is to handle tables that don’t fit in available memory. To make the persistence features robust, more engineering would be needed. “Conventional” engineering would probably use a completely different database design for backups, not just a copy of the current LevelDB state.

1 Like

I see thanks for the explanation. But why use this DB, then? That doesn’t make sense.

Performance, I suspect, judging from this post:

I have to say, I’ve moved my Core, updated many times over the past three years, and have only had one corruption incident, when I was running the Core on a MacBook. On my Linux/ext4 systems, the database persistence seems pretty stable, conventional engineering be damned. I’ve just updated to 880 without an issue.


I am troubled by this statement in a (closed) Roon Labs post:

We know that many of us have a carefully curated database: our settings, album covers, metadata, tags, playlists and favorites are exactly as we want them to be. Having to start fresh sounds like a nightmare and we do hope it won’t come to it. But, if it does, please know this is so it will never happen again.

That makes no sense. Every database started with a fresh, new database. So how can anyone say that starting fresh will ensure it never gets corrupted again?

What is needed in Roon is a mechanism to periodically check and repair the database if it becomes corrupted. That is hardly the fault or responsibility of the user! Good software always should have that. It is really malfeasance to allow the user to create a large database and have no way of fixing it when the software ()#*%#$&s it up.

It is especially troubling that Roon allows backups of corrupted databases. That defeats the purpose of backups entirely! A consistency check needs to be part of a backup.

It’s very troubling that the luxury solution to music playing is so short on good engineering basics.