Update. It crashed before I got to the Backup Status window. I then restarted the Roon app and have pushed it to backup again to a new folder location. It made it to the Backup Status window and has now finished. I will update next as to whether or not the nightly backup succeeds, which has not been completed since 7-2 for a nightly backup. You might want to look at the disconnect between the time I ask it to backup, it loses connection to RoonServer and it is then, that it crashes. In this case, it made it past that RoonServer loss, Backup Status, and ultimately a successful backup.
Hi @Brian_Fay,
Since a few days have passed, we wanted to check in and see how things have been performing for you.
We’ll be monitoring for your reply, thank you! ![]()
Nightly backups fail regularly along with an additional 2x/week backup. Currently the only way I can backup successfully is manual and into a separate location (same volume). If it starts to (or is in the process of) synch the library, it will crash. Most times, I am able to reboot the server on nucleusT and then restart roon, but then it has to synch the library again. Let me know what I can do to help.
Tried to manually Backup again due to it missing dailies, etc. It crashed again and asked me to Restore. I ignored and did not restore. I restarted Roon Server and opened Roon again. It eventually came back again, but needs to rescan the entire library again.
@benjamin Any update?
Hey @Brian_Fay,
Thanks for the continued patience, and for the detailed notes on each attempt, they lined up exactly with what we’re seeing in your latest diagnostics on 2.70.
The good news is we now have a clear picture of what’s happening, and it’s not your network or the NAS. When a backup runs, Roon validates and compacts the database as part of computing the file list. On your server that step is running out of memory and getting misreported internally as database corruption, which is what triggers the crash and the “restore” prompt. That’s also why a manual backup to a brand-new folder sometimes succeeds (it skips the step that’s failing), while your nightly incremental backups reliably crash.
Two things are feeding this: your database has grown much larger in memory than your library size would suggest, and we can see a metadata refresh running almost continuously in the background, which keeps the database churning and memory usage pinned near the top of what the Titan has available. Each crash-and-restart then forces a full library rescan, which restarts the cycle.
Unfortunately the 2.70 update did not resolve this specific path, the crash signature is unchanged from before, so I’m taking this back to the team with your new logs. In the meantime, please don’t restore when you get the prompt after a crash (as you did on 7/20, that’s the right move); just restart Roon Server. And it’s safe to keep taking manual backups to a fresh folder as your safety net until we have a proper fix.
I’ll follow up here as soon as I have an update from the team. Thank you again, Brian. ![]()
Got it. Thanks for the update.