5 ms·

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 w

by mnutt 10y ago

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.

Pxtl 10y ago
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.
- mnutt 10y ago
  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.

5 ms·

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 w

by mnutt 10y ago

Pxtl 10y ago
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.
- mnutt 10y ago
  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.