Roon Backup Verification

It should be interesting to verify database integrity before backup.

The main difficulty is : The database could still be corrupted, as the integrity checks only take into account some of the problems, they can never be exhaustive as software options continue to be added.

But… a partial integrity check is better than no check at all.


In my case, the was a clear message about corruption in the log. Pretty sure that there are other examples of corruption that would be obvious to someone who understood the workings of Roon’s black box.

Also, before someone brings it up, I am not suggesting that Roon tries to fix any found corruption.

I only want Roon to be responsible enough to send out a notification when it finds corruption and to prevent any further backups until the problem is resolved.


I was simply sharing my empirical experience with data protection and a couple techniques to prove the backups are restorable and usable.

The point is to never rely on an unproven backup. It must be restored to be deemed good.

That’s all, sorry my comments weren’t helpful for you slim

No, that’s OK. I get what you were saying.

Just, I don’t want to go down a side street that avoids (excuses) the central problem.

BTW - It occurs to me to add that it isn’t just my problem. It’s a problem for everyone who performs backups and expects that Roon will do all it can to ensure the viability of a Backup/Restore process.


@xxx I stumbled over your posts when searching the forum for other users experiences with the „There was an issue loading you database“ message and problems with the Roon database.

An interesting read which unfortunately confirms my existing concerns. I have experienced several
problems with the database about a year ago but was eventually able to fix it by restoring an older
backup, which on the hand wiped out most of my tags and other metadata I had edited and curated
over months.

After a long period of stable performance and enjoyment (meanwhile managed to rebuild most of the metadata editions I lost before) I decided yesterday to update Roon to 1.8. and that inevitably led to the catastrophe because my database crashed again after a restart of the Core (maybe due to underlying and so far undiscovered problems in the database triggering a crash after being updated to 1.8.?)

However, all my carefully curated metadata is again at risk of being wiped out again because it - other than the library of digital albums - cannot be backed up and restored afterwards to a new and clean library. Moreover, I understand that there is also a fatal risk of corruption included in my backups already which also might cause a total loss if I would be required to start with a new database or at least would be forced to restore an very early version of the backups.

While many users may not care about this as long as they can quickly reimport their albums and start
again with a new clean database, I have a lot more to loose with all the effort I put in curating and
personalize my existing database, which for me is an integral part if not the essence of the Roon user

Against this background, I fully agree that raising user’s awareness of latent corruptions in the
database - and even more important - potential corruption spreading among the backup files is very
important and should be treated as one of the top priorities for the Roon team instead of considering
further Ul changes. Some users have spent plenty of time „working" with Roon’s abilities to curate thein
libraries and the musical works they love and adore, so Roon should indeed provide a proper solution for them to safe, export and/or import their personal settings and curated metadata (e.g. tags,
playlists, …) and develope effective safeguard against latent corruption of the program’s database. And of course, scheduling regularly and possibly automated checks of the database integrity and warnings to prevent user from spreading the corruption across all further backups would be very helpful and greatly appreciated.


Brother, I feel your pain. The same thing happened to me.

Evidently this wasn’t addressed in V1.8.

Roon is dancing with the devil by not addressing this potential problem with what is an integral part of the whole design…


I would agree that this is a significant issue that needs to be addressed, as I just encountered it and directly feel the pain. I moved Roon to a docker container on Unraid a month about 6 weeks ago. Roon has been performing backups since then. I changed a setting on the container, and unraid removed the old container and setup a new one (it is kind of like uninstalling and reinstalling a software program in Windows). I then went to restore Roon, and found that every backup created in the last 6 weeks is corrupt. In my case it is not the end of the world, since I really just lost a few playlists. However, it is definitely frustrating to see this issue in an otherwise exceptional product.

1 Like

4 posts were split to a new topic: Build 778 database error

Any tips how to spot a potentially corrupted backup / database when looking into locally saved log files? Which keywords/strings should we search for?

It seems to me that one solution wold be to hold user edits/playlists/tagging in a separate area of the DB, preferably in a set of files that could be recovered if and when the main DB goes south. That way, the only loss would be all the automatic stuff Roon does to a library. Upon restore, Roon could just regenerate the larger part of the DB and read off the user changes from the separate files. As long as the music-files-on-disk structure doesn’t change between backup and restore, this should work well.

The lack of integrity-checking is insane. If this were some kind of production software tool, there would be lawsuits.

1 Like