So what happens if my case occurs? Is the backup damaged? Have I done something wrong in restoring?
Here is how I’ve used it. When I initially logged in the new server, there was this option at the bottom, saying “Restoring from a backup?” (or something similar). I hit that button, selected my backup and then let it do the restore process, concluding missing the things I mentioned above.
If the storage location(s) are not exactly as it was in the original machine that created the backup then you can loose things, as Roon is treating the audio it sees in a new storage location as “new” and not the same track that had the tags and hearts added to it.
It might have something to do with running it in a virtual environment and setting up storage. If storage is different, then when you restored, you could “Edit” the storage location and not setup new ones.
Ahhhh, I bet that’s the problem. It’s something I’ve never run into as I keep the container relative path the same, no matter where I’m running it from. The location on the host may change, but to the container, everything’s always under “/data”, such as “/data/Backups”, “/data/Music”, etc.
I just do plain ol’ bind mounts:
volumes:
- /var/roon:/app
- /var/apps/roon:/data
1 Like
Sean, you seem to understand a bit more than I do currently… 
So, what should I do in order to transfer everything correctly?
My case is that I currently have my music in my Windows Roon Server at the directory folder C:\Music. So, when I try to transfer this to Unraid, what should be done?
Because when you set up the docker, it asks for a specific folder where the Music library is stored. What should I bind with what since the initial directory is C:\Music?
Thanks in advance guys.
Ahhhhh, Windows. That’s a complication. Basically it means you won’t be able to keep the same directory path no matter what you do. In my case, I started using Roon (the server piece) in a Linux context, so I’ve always had the “/data” directory component in place.
Docker, and containers in general, mean you’re in a Linux context, not Windows. Unfortunately the drive letter thing is a Windows only thing, so C:\Music isn’t translatable to anything that’s not a Windows platform. Linux (and UNIX, which also means macOS) instead has a directory hierarchy where / is the top level, and everything else is referenced from there, so there are no drive letters.
FWIW, Unraid too is essentially a Linux system.
In short, you can’t use the C:\Music path structure with anything but Windows, so if you want to move your Roon server off of Windows, your local music, and its associated likes whatnot, will be “new” from a Roon perspective, since the path has to be different.
Hopefully that makes some sense.
I’m planning migrating from Windows to Unraid in the near future. Could it be a solution to first move the muisc files to the Unraid server but keep Roon on Windows and edit the path in Roon to the Unraid server Linux path. Then back up and restore in a container on the Unraid server?
It does make sense. I was just hoping for a way that this could work.
Is there something that could produce better results?
Maybe @TreeZorro’s suggestion could work?
The issue I see with that approach is the Unraid Linux path doesn’t exist on the Windows Roon server, so no files will be seen or loaded for the subsequent backup. The issue isn’t the path, per se, but rather that Roon appears to hold the full path as the primary identifier for local tracks. So if the full path changes, then Roon considers the changed path to be a “new” track. Given that assumption any path change would result in the same behavior that you’ve already seen, and since a drive-letter based path isn’t translatable to any non-Windows environment, you’re looking at a path change no matter what. I think it just boils down to whether rebuilding your playlist/favorites is worth migrating your Roon server to the Unraid system.
1 Like
Happy to say that I managed to transfer my Roon setup to Unraid. It way pretty painless to be honest.
All I had to do is use the Edit in the Music Folder under Storage, as per @alex_h 's advice.
Quick question about updating now. When a new update from Roon appears all we have to do is just click on the UI? Or we have to update the docker? Not sure how this works, so forgive my ignorance. 
1 Like
This is a very reasonable question.
Many apps and services have official docker distributions. The common practice for this type of docker distribution is for the distribution owner to create and release a new container for each application update. For this type of distribution, you do need to update the container for each new release.
Roon containers are different. Roon doesn’t create official docker builds. Any docker distribution you’re using is community created. Because of licensing issues, community builds can’t include Roon software, so the docker builds download it on the first run. One side effect of this is that they do it in a way that allows Roon’s auto update mechanism to update the bits in place.
So, for Roon, you don’t have to update the container to get new Roon builds when they’re released. But you shouldn’t assume that other containers, for other services, that you deploy will work this way. Most don’t.
Thanks for the analytical reply. 
It’s all understood.
The actual question is, how do we update Roon on the Roon containers? We wait for the classic An update is available notification in Roon and just click update?
Yes 
/10 char
3 Likes