I asked here:-
…if Roon verified the database backups. It doesn’t appear to be the case that it does. Could some form of verify be built into the backup (if it isn’t already there), or maybe added as a separate option within the backup manager, please?
Michael
As I tried to allude to in the thread you linked to, it depends on what you mean by verification.
If you mean checking that the backup occurred and completed without mishap, then Roon does that.
If you mean checking that what was backed up results in a viable backup that can be used to restore a working and uncorrupted Roon library, then Roon definitely doesn’t do that.
Which do you mean?
The second, definitely.
…and out of interest, what was the result of you having a corrupted backup? Did the restore fail completely, or was it partially successful?
Michael
Roon seemingly Restored, but it restored corruption.
Roon ■■■■ the bed. I had to start from scratch.
Ouch. So really, there ought to be a way of verifying existing backups. Every piece of local backup software I’ve used over the years has allowed me to do that.
There’s always this opportunity to make a Feature Request.
I was not aware of this. I’ve always thought that a Roon backup is safe to restore. Quite bad that it isn’t. Considering all the time and effort one uses over time to fix things in a library, it is downright scary if backup is not dependable 
Back up the files , if all else fails you can, however painful, reimport the files and rebuild the Roon library
Doesnt excuse dodgy backups though …
Ahh, exactly my point. 
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.
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
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.
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.
Dirk
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.