Not quite… if a program was to accidentally delete your file, RAID would not protect you.
that’s no reason to give up, it just requires some careful consideration and options to make everyone satisfied. If you have a fast enough internet connection, streaming high-res is not horrible.
I have Backblaze. It backs up all my stuff, not just music files. It costs about $60 per year. I tested the restore, and it worked fine.
I also have three local backups of my music files and everything else.
Not sure I see the value add. But that’s just me. Others looking for no muss no fuss might see it differently.
Absent any other backup strategy for music files, though, a no-brainer solution built in to roon for some subset of users would be better than nothing, and advisable.
So, yes. With qualifiers.
I don’t use an outside service for backup now, and I don’t think I’d change my behavior/plans if a service was available via Roon.
A bigger worry for me is my Roon database getting trashed and my Roon backup being corrupted. I’d rather have piece of mind that having two staggered Roon backups could not somehow become ineffective.
Right, I was talking about the data cap and/or people doing their own transcoding. I should have made that more clear. I wasn’t saying to give up or that it can’t be done. I know it can be done. If I can stream hi-res movies on my phone, I can certainly stream hi-res audio.
Live storage and/or redundancy are not equal backup. Content sync is not backup. History may (disputably) count as a backup only if outlives the original file (if you delete the original file you can still have access to the history).
I believe you are missing your own point (“Is there any interest in a music files backup solution?”)
If most Roon customers are streamers where’s the attraction in offering media backup as a service?
You are confusing redundancy with backup. A RAID is a solution (one of many) to the hardware redundancy problem (if one or more disks fails, data is still available). In your RAID system if you or somebody else accidentally delete a file, that file is gone forever (in your specific case is deleted from both disks). A problem that you can avoid by having a backup - copy of the the same data in another system (another RAID, cloud, both and so on).
Yep, this is what I would like too. My music library is currently stored on my “unlimited” Google Drive, and that works very well (apart from all the current bugs in Roon 
), but if this would somehow be integrated into Roon I’d gladly pay a few bucks extra per month.
I use that service too and did do a restore, went smoothly (umlimited storage for 75 Euro/year) . Downside, no linux (qnap/synology) app.
Yes, this is the missing piece that would shift me from RoonServer on a Mac to Roon OS on a NUC or Nucleus. Without backup, I’d have to run the Mac server anyway, and that’s just too much of a pain.
My preference would not be a Roon-branded or -run backup service, but to integrate some preexisting service. I use Arq presently, with AWS Glacier for storage, but am not wedded to it at all. Maybe something with AWS or Google for storage? Or Rsync or Borg to any generic host specified by the user would be excellent.
If it matters, Borg is BSD licensed.
Sure, run as an ‘Extension’ to RoonOS, to a backend service - a scheduled rsync job.
May have to consider data security & privacy, as you are archiving an individual’s data for them and storing it on their behalf as a service.
The users all come from different countries, regions, jurisdictions with differing data security provisions, e.g. GDPR which works on where the data holder resides and not where the service is operated or the data held.
Plus ensuring that any restoration of data is undertaken by the individual that put it there, and it is just not a big remote copying service bypassing all copyright laws.
Oh yes, ensuring that the individual availing of the services is correctly licensed to make a copy of the material and store it in a remote service.
What”s in that for roon? If Roon does that they won’t make the extra monthly revenue. They’d just be making it easy for others.
I’m not saying it’d cost them nothing to create and maintain the service, but it seems the reason Danny is asking is because it’s probably not much more work on top of the servers they maintain now to add a dedicated roon user backup solution… that is if people would use it and pay for it though.
But then you have people already paying for a backup solution so they’d rather not pay for another just for roon.
My head hurts. 
Live implies accessibility. Who says backup must be inaccessible? I agree it should not be deletable, but it’s accessibility does not preclude it from being a backup. In fact, non-accessibility does not always imply safety. Roon database backup is accessible and is just fine backup.
Content sync can come in many forms. If you assume rsync -a style sync, then I’m agreed that sync is not backup. But if the sync process never clobbers existing data, then it’s a perfectly fine backup.
Of course. This is how the Roon database backup works. In fact, while it does back up corrupted files (because the backup doesn’t check for validity of the content), if your history is old enough, it’ll find you a good version from the past. It also does this incrementally so it’s not a complete copy for every snapshot.
I still don’t understand. Please tell me concretely how I misunderstood your definition of “backup”. I have a concrete implementation of backup in Roon for the Roon database. It not a rsync -a. It’s incremental and holds history, even through deletes and modifications.
I’m no backup expert, but I have given this thought. I’m genuinely interested, so please show me how to improve my definition of “backup”.
Most Roon users have both streaming content and files. It’s one of the core value propositions of Roon.
Given by the interest already given here, it’s interesting to see how the use cases fit. I really like that the “stream to phone” use case has already been brought up.
Are you still files-only? Are you interested or not?
Read only data doesn’t count as a backup, because some user level will always have delete rights. It may also be impossible to achieve depending on whatever backup solution implements the backup (think secure copy , when the old data is deleted after the new data is successfully transferred).
It does, but doesn’t go both ways: live data is the data an application is actively using (main roon data base for example). Accessible data is data to which I have access. Main data, backup data, archive data all of them can be (or not) accessible, but only the main data should be live (which indeed implies accessibility).
See above or even more: roon server does not work over the backup data. It works over the main database, which is considered in this case live data. The backup is a copy of this data.
The closest scenario in which you use the “backup” data (note the commas) as live data is the replication, but this is I believe out of the scope here.
The definition is not mine (or yours for that matter) :). So, you are asking me what about a “backup solution” for my music files. Well, what I personally understand by that, is that you want to offer me a way to have another copy of my music (that’s a backup).
Then you give me some details about how do you see this …
…and all that I can tell you is that this is not a backup solution (by any definition). It’s just a cloud based live data solution (which can be complicated by duplication, synchronization or whatever).
Now, what i believe it will be the right approach to this, it’s to split it in two: live (playable) data, eventually in sync with my local data, that’s one thing (think OneDrive for example). And a back-up solution to all that data, that’s the second one (think B2, which in this scenario will backup my computer including the OneDrive data, for example).
If I correctly understood and you want to use the same model for the music files and in addition to have the files playable, then just don’t call that a backup, because it is not, that’s all.
But B2 is live and can be used for streaming!
We’ll have to disagree on this detail since I was think we agree on the rest.
My position is that if you have a bunch of data off-site from your live set at home, and it happens to be historically rewindable, then it is a backup. If you are able to use that data set in a manner that cannot destroy it, then it is no less diminished as a backup. You may think that that voids it as a backup, but that’s where we disagree.
That’s not what I’m suggesting. You don’t get to delete your local files and only use the cloud storage. It just gives you an internet accessible place for remote access to your live files. Your deleted content would not be accessible other than to restore. This property would make it closer to a backup in your mind, correct?
But, more to the topic on hand: would you be interested in such a service?
And this is where it’s not working: sometimes I want to delete files I currently use for playing music, but I don’t want to lose them (for example when I get a higher definition version of the same album). If I play from the live data, then I’ll just go and delete whatever I want and it will stay in my backup, as I want. If I’m actually playing from the backup, once deleted there, deleted it is. There is a reason for which a backup is only used as a backup and the live data is live data.
As far as my understanding goes, you didn’t yet defined the service you want to sell me. Regardless, no, I’m not interested because I already have some other mechanisms implemented for all my backup, live data or combination needs (larger than but including the music files).
That’s a use case I did not think about, because all the online backup services I’ve ever used (crashplan, backblaze, dropbox) eventually delete files that I no longer have locally.
I see the issue you have… if it was not-live, it would be ok, since the backup is just backup. But as soon as you give access to the currently live files via the backup, you cant use the backup as a backup only because you must keep local files lingering to retain remote access.
Thanks for helping me see the gap in my understanding… it’s subtle, but real.
I’ll have to think about whether the lack of this use case damages the project’s commercial viability.
I use IDrive, which has (somewhat clunky, a bunch of Perl scripts 
) Linux support. It’s encrypted.