Corrupt database “Issue loading the database” after the new update. Before it was fine!
Have tried recovery from my last updates i have on dropbox v1.8 (i only save 2), if i do a recovery on them it is still the same fault(Issue loading database). But if i do recovery from a 1,5 half year old backup i had on my server v1.7 it works. Please help dont want to lose all info since 2020…
I’m so sorry to hear about the trouble you’re having loading the Roon database. Typically, problems loading the database mean that it may have been corrupted at some point. We have more information about what can cause corruption and steps that you can take to recover your database here:
If you’re having any issues after following the recovery steps above, please let me know!
As an aside, right now our team is working on some changes that will help our customers detect corruption when it’s happening. If you don’t mind, I’m hoping you could take two minutes to send us your corrupt database. That way our team can analyze the type of corruption and prevent similar cases in the future.
Until Roon devs get their act together and address a problem that has existed since the beginning, then taking multiple Backups on different schedules and with different retention periods is the safest bet.
There’s two problems to be addressed; stopping corruption from happening to begin with and stopping the Backup of a corrupted database. Either one without the other is not sufficient.
If there’s anything I currently hate about Roon it’s the paranoia inducing fear that my years of curation could be wiped out, simply because there’s no way to check the integrity of the database. Yes, I back up to multiple locations, on different schedules, and keep copies that go back over a year. I also run a restore about once a month, to check the integrity of my current backups, but who’s to say that I don’t already have some ‘latent corruption’ that I’m simply backing up as I go along, which - at some point - will cause my database to fail. I’ll sleep better when this has been fixed.
Yes, I don’t understand Roon’s attitude about this. They play fast and loose with the most integral part of the whole invention.
I suppose it’s ‘sexier’ to come up with tantalizing GUIs and spiffy data mining, but at some point basic good programming practices have to be attended…
Yep, it’s all a bit ‘wing and a prayer’ at the moment. I’m doing everything I can to avoid having problems down the line (including running my new Mac mini through a UPS) but, having read all the current and historical threads on database corruption, it seems that being careful isn’t always enough.
I’m sorry to hear that your other backups weren’t working, @Johan_Gustavsson. Typically, when this type of issue occurs, these backups have latent corruption which means the corruption exists in the backups as well. In those cases, there is no way to recover from those backups.
As mentioned above, our team is working on some improvements to this to try to catch corruption earlier on. If you’re interested in helping, please upload the old database to the link above and our team will use it to try to prevent issues like this from occurring in the future.
Hi @dylan , I know that Roon are often fairly tight-lipped about what’s happening behind the scenes, but could you elaborate? For example, “catch corruption earlier on” sounds like a step in the right direction, but something along the lines of “prevent it from happening in the first place” or “fix it when it does” would have been more encouraging. Catching it earlier is clearly a good thing - less likely that earlier backups will also be toast - but still not 100% reassuring.
I don’t have the full details on the changes that are coming, but ultimately the goal is to be able to perform integrity checks to know if something gets corrupt so it can be resolved by restoring a backup and looking into the issue.
Preventing corruption from happening is a good goal, and it’s definitely something we already strive for, but there are a lot of reasons out of our control that can cause corruption. Most often we find that corruption stems from failing hardware which we can’t prevent. Our upcoming changes should help identify when problems occur, though, so they can be caught before it becomes a problem that can’t be recovered.
This is all a work in progress and I can’t provide any timelines or further specifics, but we’re confident that we’ll be able to improve reduce the impact of this class of issue in the future. Keep an eye out during future updates for more info!
Integrity checks would be great, especially if this is something that can happen in the background - warning the user before anything too serious can occur. Fingers crossed that “ultimately” means fairly soon rather than later.
Absolutely (and exactly why I added a UPS). I don’t think anyone’s out to suggest that database corruption can be avoided altogether, or that there’s anything especially wrong with the way that Roon have chosen to implement their database. It’s more a case of yes, it happens, but what can we do about it when it does? And, thus far, the answer has been “not very much”. I’ll watch out for future updates.
I was going to make a joke about watching out for updates regarding Roon mobile too, but thought better of it
I am experiencing the same problem on two Roon servers (a Rock and Nucleus +). Would it be possible to come up with a utility that does integrity checks against the backups? I have multiple backups that go back a few months, but loading each and every one backwards to see which works gets old pretty quickly. If I could do the checks against the backups, that will also later help in verifying that the backups I have on hand are uncorrupted, and usable, and will keep those.
I’ve gone through eight backups and its failing. Whats the point of backups if you have undetected integrity issues that prevent them from being restored. While the cause may be due to external sources conditions, this is a major ROON product deficiency overall that needs to seriously be addressed.
I am so sorry we didn’t get back to you until today… . It’s not a sign of lack of interest, more of the size of the workload.
As Dylan has said, our R&D team is actively working on finding a viable solution to avoid corrupted databases. While we don’t have timelines, we want to assure you this is a topic of conversation within our teams.
I am so sorry about the amplitude of the impact in your case…it is definitely not what we had hoped or intended.
We’re grateful to still have you and for your patience and trust that we are prioritizing this
`
. It’s not a sign of lack of interest, more of the size of the workload.