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...
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...
The software screwed up and his backup strategy failed. The software didn't screw up because his backup strategy failed.
> "All my backups were the encrypted data, so those didn't really help either."
My guess is that the "bad encryption" simply was replicated over his "backup".
If you can't go back in time, a backup is worthless.
Ransomware are a thing, people, when will you learn?
Restoring from backup would have corrected the symptom, not the root problem: a bug.
It wouldn't have even been possible to backup the encrypted data without getting all my family members passwords too.
> 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.
He did have a backup. Having it also be mysteriously borked certainly violates the principle of least surprise.
That's a bug like Fukushima is an industrial accident.
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.
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.
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.