Roon Backup Verification

Ahh, exactly my point. :slightly_smiling_face:

Absolutely, but when the Roon library goes south one loses all the tags, playlists, endpoint setups, etc.

Not so bad for me as I don’t curate much and I only had one playlist. It was a big playlist, but since it was of tracks I like to play when I drink, I’ll have other opportunities to recreate it.

1 Like

Fortunately I have never had to depend on my Roon BU , I have used my MC back up on occasions when I have adjusted Tags incorrectly.

Should the need arise I would be very upset if it didn’t work. Just importing my 6500 albums would take days let alone any adjustments like Tags and Bookmarks

1 Like

Base functionality. Not a „feature“


Same here. All those unidentified albums that I’ve identified…

Yep. Spend countless hours trying to make sense out of what Roon has made of my collection…

I want to clarify what the real problem is.

If a Roon library has ‘latent corruption’ it can still be used for some period of time.

Because Roon doesn’t bother to make even simple checks to see if there is ‘latent corruption’ it will blithely backup the library. If the Backup is ‘successful’, then no further errors are reported.

When a Roon library with ‘latent corruption’ inevitably ■■■■■ the bed, if the corrupted library has existed for awhile and through a number of Backups, then it is possible that all the good Backups have been overlaid with backups of a corrupted library.

In this case, no Restores will salvage a corrupted Roon library. Only starting from scratch will ‘fix’ this state.

Since Roon logs seem to (in many cases) report a corrupted library, one solution is to check the logs, which could be done concurrently with the backup process, and if corruption is found then throw away the backup, put out a warning message and don’t do any further backups until the problem is resolved. In this way, no good backups will be overlaid.

The resolution, of course, is to Restore the library. Now this will work because no corrupted Roon library has been allowed to be backed up.


Well understood. So it needs to get fixed.

Working with data protection for 30 years (we don’t call it backup as that’s only half the story) the only true way to know if a backup is good is restore. Verification is a nice to have but doesn’t mean much in the end if the restore fails.

Small SSD drives are cheap these days. Setup a mirrored drive to hold Roon db, two identical SSDs. Setup everything as normal if not already done. Create a backup. Break the mirror preserving one disk untouched. Restore the backup…

Alternatively, setup another Roon core and restore to it. The license will prompt to be transferred to the new, and back to the original…

Sorry, the Backup/Restore isn’t failing. The process is just operating on a failed library.

Once Roon offers a Backup solution it is Roon’s responsibility to do whatever it can to ensure that the Backup/Resore function offers some insurance. Particularly, when that insurance could start simply by reading the logs and looking for a message that indicates a problem.

Huh? It’s almost like you didn’t read what the problem is. How is Restoring a corrupted Backup to another Roon Core going to help?

Once again, huh? You’re not getting the point.

1 Like

Although my experience is 100% inline with your statement, in the end this is not really feasable. How many times will a user test a restore? Maybe a couple of times, but in the end, he will just stop.
In the case of Roon, there is even a bigger issue. Often, the database structure is altered between different releases or release updates.
So a valid backup from a previous release might be unvalid for a new release ( not necessarilly but might).
I fear there is no riskfree solution to a 100% guaranteed backup.

Also, the problem is, for the case I have described, the Restore will have seemed to have worked.

Granted, nothing is fool proof, but Roon could/should do a lot more to ensure the integrity of the Backup/Restore process.

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?