I was doing a backup of my Win 10 computer where I run Roon core. I noticed the Roon backup folder (which is in my Documents folder - not sure if I choose this originally of if this is default) is 3.20 GB in size (not a problem in of itself) and has 14,647 files & 35,950 folders! Is this “normal”? If so, what is the purpose of this sort of structure? It strikes me as some sort of almost ad hoc database structure reliant on the OS filesystem.
Yes, nothing to worry about.
what is it exactly?
thanks…I wondered if it was some kind of data aray and why a real sql was not used. it sure slows down a backup, creating as it does a rather absurd amount of folders and directories.
Roon, what is this data, and what would happen if I deleted this thing?
Its your Roon DB… And you would lose your library and edits if you removed it.
And there has been several wishes that Roon packed things up neatly as a better vessel for backup and restore. (Such as an automatic zip-function)
Like you, i and many more have reacted to the absurd amount of time it takes most OSs to handle that file and folder heap of several Gbytes.
The Roon Backup feature was introduced to enable users to avoid manually backing up. You can use Dropbox or a thumb USB stick (I use this), schedule a Backup at 3am every 3 days (say), leave your Core on overnight that day and never be bothered about how long it takes.
I’m sure that the Roon database could be redesigned and a more efficient Backup devised, but is that where we want development resources spent ? Provided Backup works and I don’t have to think about it, then I’d prefer Roon to work on other stuff.
I agree, we have other features we are waiting for such as mobile sync and improved internet radio. Much better use of their time when the backup system already works.
Notice I was not talking about an internal Roon backup, but a backup of my computer (so outside of Roon and an OS function) - which also of course includes the Roon application and backup directories. Roon’s choice of DB, which by design creates a many-thousand numbered directory structure, is not really what OS’s such as Windows are meant to handle (not in a home environment), and so it takes an inordinate amount of time for the OS to back up said structures…
I’d exclude the roon directories from.the normal backups.
Yep, that is where I am at as well.
edit: I asked the question because this was my first encounter with Leveldb. Whatever its advantages for Roon (besides it being free), it had this obvious disadvantage for the end user…
I believe it is multi platform and is good at updating across a wide address space rather than drilling down. If you think of your library and the links I guess it is good at that reach across as you add a track to a playlist it also updates all the associated metadata across many hits in your library.
Is this really something to cry about, having to make a backup that takes some time?
Here’s why Roon uses leveldb:
You don’t know my use situation. Yes, it really is something I have had to adjust for. Marketing speak about this particular database can always be countered with equally impressive sounding marketing speak about some other DB choice. Whatever it’s real advantages, I note its cost (as in free) and its effect on my file system and backups.
Ok, you have my sympathy. Perhaps you should look to another tool that isn’t data rich and doesn’t provide a near instantaneous data-driven interface. Your backups will be a lot quicker.
There is no such thing as a for all uses database. Roon have made a choice which for access for read across many data structures trumps peripheral actions such as backup. Really, don’t start second guessing architectural decisions without all the facts.
Perhaps you should just admit that yes, there is a downside to Roons choice. They are big boys, they know this - why do you seem resistant?
Second guessing? You mean like everyone around here does about their recent 1.6 UI updates?
Really, what’s the beef? Roon’s choice has a real and unusual end user impact. Whatever its positives, it has negatives. That’s the real world…
You’re right. You should post a feature request that Roon modify its architecture to meet your backup time requirements.
Imagine the stress and complications it would cause if the Roon database looked anything like mine:
I imagine that would take some time to copy.