Hacker News Reader

He probably thought he had a backup:

> "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?

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.

"You're holding it wrong."

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.

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.

The problem was that encryption totally broke after an update. A symptom of that problem was that files became inaccessible.

Restoring from backup would have corrected the symptom, not the root problem: a bug.

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.

>>> 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.

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.