Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wouldn't call it a backup without further clarifications. Like, if it can be killed by the same power surge that takes your main server out, I wouldn't call it a backup.

There are a lot of ways to introduce redundancy in the system that would make backups needed much less frequently (if ever).

But what a backup does is it allows you to have your data in case your system and accounts are compromised, whether through a misuse, failure, or an attack vector.



ANY backup solution can go down with a big enough disaster.

An on-site backup is A backup, but it shouldn't be the ONLY backup. Typically you want a hierarchy of backups, one of which is on-site and on-line but a different machine, another of which is off-site but on-line, and possibly one or more offline backups. But on-line backups are fine, IF (and only if) they're copy-on-write/append-only.

Of course if the data can be deleted or overwritten too soon (even tape drive backup systems have some period over which they start re-using tapes) it's worthless. But that's an entirely separate concern from whether it's always-on or internet-connected or on the same national power grid segment as the original.


I was with you through the rest of the thread until here, but this is too extreme. By your definition there does not exist such a thing as an in-site backup, does there?

Take it to the extreme and everything is connected somehow at some point, thereby making a True Backup by your definition physically impossible, even off-site. The point where the backup is made could have a zero-day propagate to the tape machine, killing it and the tape by spinning up the motors. A blueray drive could have the firmware pwned.

If not even incremental snapshots synced to a remote count as backups, you are probably the only one to harbor this interpretation of the word and it arguably loses its usefulness as a word.


Well, as long as you can recover from an onsite backup after logging into your system and completely destroying everything you can, it counts.

An incremental snapshot to a remote is as good as a backup as WD users just found out.

>The point where the backup is made could have a zero-day propagate to the tape machine

Again, the point here is the failure of the backup is decoupled from the failure of your system.

Again, everything is on a spectrum, and we can argue about definitions, however, a copy on a hard drive that's sitting on your bookshelf is decoupled from whatever happens to your computer unless both get destroyed (or stolen) - and that's how good that backup solution is.

The data on a RAID array will go poof if you accidentally rm -rf that partition, so the chances of it failing when the system fails are very high. Hence it's an awful backup solution.

What you have to consider is not whether the chances of failure are high or low, but where the chances of failure of both the system and the backup at the same time are non-negligible.


Well, as long as you can recover from an onsite backup after logging into your system and completely destroying everything you can, it counts.

An incremental snapshot to a remote is as good as a backup as WD users just found out.

>The point where the backup is made could have a zero-day propagate to the tape machine

Again, the point here is the failure of the backup is decoupled from the failure of your system.

Again, everything is on a spectrum, and we can argue about definitions, however, a copy on a hard drive that's sitting on your bookshelf is decoupled from whatever happens to your computer unless both get destroyed (or stolen) - and that's how good that backup solution is.

The data on a RAID array will go poof if you accidentally rm -rf that partition, so the chances of it failing when the system fails are very high. Hence it's an awful backup solution.

What you have to consider is not whether the chances of failure are high or low, but where the chances of failure of both the system and the backup at the same time are non-negligible.p




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: