I don't mean to belittle the severity of the bug you encountered -- but the root-cause of your problem was a lack of a backup. A large number of issues, some of them software bugs, many of them not, could lead to data loss.
No. The user should have a backup, but you can never blame a software problem on a lack of backup. That's like blaming a car-accident malfunctioning airbags.
The software screwed up and his backup strategy failed. The software didn't screw up because his backup strategy failed.
Yep, if your backup software doesn't have historical snapshots where you can jump back to a certain day, you are just going to write bad data as your backup and only have bad data to restore.
>>> Everything went smoothly for about 6 months until I was updating Owncloud with a minor version upgrade, and then BAM; nobody (myself included) could decrypt any data on the server.
> Do you back up the unencrypted data though? Regardless of the viability of the raid 5 system, the raid 5 wasn't what failed. It was the encryption.
> It wouldn't have even been possible to backup the encrypted data without getting all my family members passwords too.
You could have backed up the encrypted data (+owncloud metadata) in its encrypted form. Then, when you ran into the bug that corrupted the main copy of the encrypted data, you could have restored the old backup of the encrypted data and reverted to the last working version of Owncloud to access your data.
If you're backing up encrypted data, then yes, you need to (facilitate that your family) back up the keys to that data as well. Obviously not in the same place, as that negates the purpose of the encryption.
Backups are hard and you absolutely need to do them right, otherwise they're pointless.
The reason you need backups is exactly that you can't trust other people (or yourself) not to epically fuck things up. No matter how unambiguously totally someone else's fault it is, if your data is gone, it's gone.
If you want to rely on backups, you have to test them periodically and not overwrite older ones with newer ones. It sounds like the backups had probably never worked, or there was some necessary component that was not backed up.
Considering the number of problems we describe in backups
1) You need incremental backups, not just a live copy, so you can rollback.
2) You need redundancy both connected/disconnected and offsite.
3) You need to test restoring.
All these requirements... how do we not expect the user to screw up? This is like crypto, except every idiot knows "don't roll your own, you'll screw that up and leave a hole".
Same problem with OwnCloud itself - it requires too much configuration, as the OP explained.
Why are we doing all this garbage manually? Where's the automatic backup solution that provides differential incremental backups so you can rollback to various points, integrates with Google/Dropbox/whatever, integrates with OwnCloud, lets you plug in an external HDD for regular disconnected backups, etc.
Right, no arguments here. Backing up is really hard. Many backup systems are "push", and so you have to limit the production system's access so that it can't maliciously overwrite old backups.
From what you describe in the last paragraph, that sounds like a special Owncloud client. It needs decryption keys and it needs some automated tests for verifying the backup which vary based on your use case.
I've recently been testing git-annex with the webdav special remote, and it mostly solves the integrity piece but a) if you want encryption you lose the web UI, b) even if you don't want encryption, you still lose the web UI because there are no indexes, and c) it would be too high a bar for most people to set up.
It that vein, too, your RAID-5 system is/was a disaster waiting to happen, especially when you don't have a backup: http://www.zdnet.com/article/raidfail-dont-use-raid-5-on-sma...