Hello there… first I want to say that I really like how one can configure automatic backups and forget about it and be all safe!
Fortunately I never had to really rely on backups anyway. I run Roon ROCK on a dedicated NUC8i5 and this solution does its job reliably and well. But since I have learned that Roon backups are incremental and agnostic to the platform/OS, I got curious about how my MacBook Pro M1 would behave and perform as a core.
So I disconnected the NUC and restored the latest backup (from yesterday 4 am) on my MacBook. The procedure went flawlessly at first glance and after successfully restoring, Roon restarted but then started to import and index all music again, which a) took hours and hours und b) left nothing like it was before. I am referring to the view „albums recently imported“ in particular which I use heavily and which looked NOTHING like one day before in the NUC.
So here is my question which I - even though it may sound a little sarcastic - don’t mean rude, but: why perform recurring incremental backups when after restoring the database seems to be build completely from scratch?
I mean offer stuff like my tags, Playlists etc… that worked fine. But doesn’t Roon save „date imported“? For the way I am using Roon this would reduce the benefit of recurring backups to 30% or so. I mean what does Roon actually backup (despite tags and playlists) when it starts to import and index completely from scratch again, leaving me with an album view in said category which looks nothing like it did before?
Is this a bug or normal? Or just an unable user? Looking forward to some input from you guys.
I don’t make backups just for Roon because of the time it takes. As I always want to have a working copy of every disk in the office cabinet. Clonezilla (free) does it for all operating systems so that really a safe working 1:1 copy is created.
@joel Thanks for the important note, yes a really good backup will only ever exist if you don’t make any mistakes.
Clonezilla Clonezilla - Downloads
is put on a small memory stick or SSD and told UEFI/BIOS to boot from it.
It’s practically its own Linux operating system just for this purpose. So no other systems are active and ready for the 1:1 copy. Maybe you can make an agreement with the developer to use it by default as well. However, there would then have to be a removable SSD/HDD in each device that could not be attacked by the Internet.
I’m not actually 100% sure (not my area), but it’s essentially everything in (or everything needed to reconstruct) your database. No longer includes images.
That would be my understanding as well. It takes a long time to rebuild all indexes on a new machine for large collections. What is rebuilt is decided by the user with his import settings.
According to Roon’s knowledge base “Networked storage devices (like a shared folder on a NAS) will work without any further changes after restoring”, so I’d say it isn’t normal for Roon to be importing and indexing everything again.
If you go to ‘My Albums → Focus → Added in the last → View more’ what does it show?
I know, but that doesn’t change the fact that the knowledge base seems to imply that importing and indexing won’t be necessary if the files are stored on a NAS. I interpret “Networked storage devices (like a shared folder on a NAS) will work without any further changes after restoring” to mean that reindexing won’t take place, but maybe it just means that you won’t need to re-enter the storage location after a migration … but, subsequently, it will all be re-indexed etc. Hopefully someone else from support will be able to clarify.
My experiences switching between Windows 10, 11 Linux Mint, Manjaro and a bit of switching between macOS and Manjaro tells me there is more going on here within an OS family than switching. Sometimes it already helps to adjust the drive detection manually.
Be it as it may… Note to myself: the most important parts (for me) of the backup are useless… having a quick overview over the newest records in my library is the most crucial thing for me in Roon.
If a new core can’t reproduce this “as it was” after restoring a backup, said backup for me is nonsense because Roon loses large parts of its convenience then.
@Uwe_Albrecht I get what you said about import settings… but isn’t that like a cat chasing its own tail? I assume the following: when a user performs a backup and restores it, he will want everything to be like it was before including the import settings he had chosen before.
So, I still don’t get it. There should be no need for Roon to go through all the initial pain of setting up a database again (which all the downsides for the user). That is why I am backing up! If I wanted to have that fuzz again and again I can just manually tell my new core where the music is.
Just to clarify, you did follow the process given in the “Moving Roon to a new Core” article, didn’t you? Because if so, I wouldn’t expect the Core to start afresh with creating a new database and re-importing everything - which is what it seems to have done in your case.
I have done nothing wrong according to the documentation you just mentioned. I didn’t read it before, but the steps to take are evident and were done according to the documentation.
The critical steps considering the migration of music files or backup files are not an issue in my use case, since both “live” on my NAS.
I have absolutely no idea why Roon would want to import and index the music again.
I’m interested to know the extent to which database migration works if local content is physically moved (e.g. from NUC internal SSD to USB SSD, or NUC SSD to NAS. In this case, the path to the content will change at some level. If time has been invested in fixing unidentified albums, managing versions, curating genre customisation etc, will all that have to be re-done from scratch?
