Changing the subject, does anyone have “THE SOLUTION TO DATABASE CORRUPTION”?
😵💫 
4 Likes
Not for a pre-B880 Roon Core database, no.
5-days now invested (wasted) into building a new one, and trying to get it back to how it was at B831, before the failed update wiped me out.
1 Like
There is no solution. Roon just tells you there is a problem now. Before it didn’t check until it was too late to do anything about it. Now, the “do something about it” is it tells you to restore a copy / backup of the DB which is not corrupted.
As a reminder to all, Roon performs incremental backups via its scheduler (optimized for storage capacity, not resiliency), so “multiple backups” requires “multiple schedules”, unrelated to the frequency chosen for any particular backup schedule.
Periodic manual backups, which are full snapshots, is likely a good idea.
Are you saying that regularly scheduled backups, as specified in the Backups>Scheduled Backups section of Settings, are not full backups? And that manually triggering one will backup more data than a scheduled one?
I have Roon set to backup every 7 days. As far as it tells me it has done this successfully since I scheduled it, months ago. I have never checked the actual backup. I am not having any issues currently with Roon, working well on latest build afaict.
Thanks for the warning.
Edit: I will note that I also have a Time Machine backup that includes the media and backup drive, so they are double backed up. Still, it is one single snapshot of Roon DB, just in two places.
Edit 2: I mean to say, I understand that the scheduled back up is incremental, just as a TimeMachine backup is. But theoretically there should be a full backup aggregated at any given time. Running it manually will force a full back up, I understand that. Is it necessary? Do we think there are issues with the backup system in Roon?
And, I realize Roon’s BU is only backing up the DB, not the local media, so I only have one back up of that, but I’m fine with that situation. So far, fingers x’d, no drive failures in the last few years. Going back several years ago we regularly had platter drive failures, at home and at work (high intensity large file servers). Since migrating most drives to SSD… a lot less of an issue. A welcome respite. (I do use DriveDx to keep me abreast of potential issues.)
My only intended point is that for every backup schedule there is only one copy of any particular piece of data, so if there is any problem with it for any reason (without making any claim as to the cause), that entire backup set will not be viable. If you want two actual copies (say), you would need to create two schedules. Or perform an additional manual backup. Or manually copy the backup directory somewhere else.
If a backup has run since you updated to build 880 (or above), and it didn’t report an error, then your database and backup should be in good shape. If you do want to check it, run a restore. Prior to 880 I periodically restored from one of my backups to check. In theory, this is no longer necessary.
Yes, it has run since updating I believe. I will not poke the bear by ‘trying’ a restore. I’ll just quixotically move forward enjoying music. I hope others can solve their DB issues asap. How frustrating. Thx for the responses.
1 Like
I’ll just throw out that there is one hint to one person’s isolation of corruption that affected him, and which resulted in a work-around. This yes neither endorsement nor comprehension on my part, but a right for those who are in a bad state who need a thread to grasp at.
1 Like
I have always thought that Valence was going off of Roon hosted data. That all of our “Valance listening histories” did not start until Valance was launched and that it did not look at prior playing history or your local database. Probably assumptions on my part vs. actual information.
In any case, I do place high value on what I would call “personal metadata” — playcounts of tracks and artists, “likes” on tracks (which i thing get saved to a streaming service). Last.FM does this to some extent (if you have it turned on in Roon and other services)
Could we maybe make some attempt to stay on topic here?
Pretty sure both race cars and airbags have very little relevance to " the solution to DB corruption’…
7 Likes
I have a new database rebuild in B88x given my previous B831 and all backups were toast and non-runners, so have lost playback history since 2015, playlists etc. but could import from Last.FM, as they have my history since circa 2017.
Regarding your request, TheHammer, I would be happy to return to the topic of the original thread. However, I still don’t know of any other solution than setting up a completely new database. RoonLabs has reacted little constructively and the user community is too badly positioned on this deep technical level. All relevant threads regarding this subject, including the one I started (“Some Words regarding Support & Service in connection with Build 880/882/884”), are now lost in off-topic discussions.
I had something like this implemented, except the very last one. I figured 6 months would be enough time to discover any issues. I was wrong. All my backups going back as far as August 2021 are corrupted and there appears no way to fix them, no way to repair or salvage data from the existing database, and I will lose years of edits and all my playlists.
That means for 6 months moving through every upgrade from 814 to 884, with daily and weekly backups running all the time, at no point did Roon run any kind of checks to determine if it was simply backing up bad data.
I don’t understand why it isn’t possible to salvage the “good” records into a new database and have only the bad entries removed and re-added.
With the new database checking this should - in theory - not occur. But there is no visibility as to when the database check is running, under what circumstances it runs, no progess info, no option to manually run it, and no result displayed.
1 Like