Hey @Celts88 – first off, you have our apologies for the trouble here, and for how long it’s taken to get this worked out for you. I know the Support team has been tracking this issue closely, and they asked me to check in with you last week. My attention has been pulled in a few different directions since then, and I did not have a chance to read over everything and get back to you. This was going to be a PM, but anyway…
Looking this all over it’s clear the issue dragged on for too long, and I’m going to sit down with the team tomorrow to make sure we understand how this could’ve been resolved in a more timely manner.
That said, I want to be clear about a few points.
First off, we’ve never seen Roon’s backup feature fail as you’re describing here, across tens of thousands of installations. If we had reason to believe Roon backups weren’t safely and consistently preserving people’s databases, our development and QA resources would be 100% focused on reproducing, resolving, and releasing a fix as soon as possible.
In the first weeks of February, we actually did have another report similar to yours – an apparently-successful restore that failed to actually restore the user’s information. Two reports like this is absolutely cause for alarm and we took a close look at these reports in February. After working with the other customer and receiving an upload of their backup, we were able to confirm that archive was not actually corrupt in any way. With that information in hand, the issue was subsequently traced to a bad hard drive in the machine the customer was restoring to.
Like any backup feature, this functionality is designed to enable a backup strategy – they allow you automatically make periodic copies of your database, but they don’t preclude hardware problems, external factors tampering with the archive, or corruption in the database that predates the creation of the backups. These examples probably don’t apply here and they’re all quite rare, but they illustrate causes that don’t have anything to do with the backup functionality itself. As always, we recommend backing up regularly, and to multiple locations if possible.
There are also a few minor bugs related to our backup feature that we are currently working on right now. None of these bugs can cause corruption of backups and they’re primarily annoyances, like issues deleting older individual “snapshots”. I mention unrelated issues to draw a distinction between bugs that affect the experience of using Backups, and major issue like you’re suggesting may be afoot here, which would cause corruption and data loss.
Others seeing this thread may make assumptions about backing up, so I really need to be clear that we are not currently aware of any major issues with our backup feature. There are a number of possible causes for what you’ve described, including the environmental causes I mentioned above. Unfortunately, it’s hard to make definitive statements about the environment in which the backup was created since I believe you no longer have access to that system.
We would also know more about the status of the backup archive if we had a chance to run diagnostics on it. I understand these archives can sometimes be 10 or 20 gb, but looking back I can see that the copy we received from you in mid-February was missing the bulk of the actual backup data (with the “objects” folder removed), This makes it impossible for our team to give you definitive answers about the integrity of the archive, which is how we resolved the other February report I mentioned.
I understand (and share) your frustration about how long it’s taken to get things square for you here. At the same time, people use our Backup functionality every day to migrate to new Core devices, and I personally depend on it to preserve thousands of edits, tags, playlists, plays, etc.
Clearly something went wrong here but there’s more we need to understand about this report. For now, nothing I’ve seen points to a more serious issue. As such, suggesting that people shouldn’t rely on Roon Backups is premature. I’ve edited the name of the thread to reflect that, and we’ll be in touch soon with next steps. Thanks @Celts88.