Hacker News new | comments | show | ask | jobs | submit login

> 1) Have all your nodes syncing at the same time and connected.

That's not necessary. All you need is your nodes to connect and sync at a time before you notice a problem, or if after you notice a problem but accidentally let it connect (consider a non-technical user here).

> 2) Introduce file corruption and deletion.

If this didn't happen, you wouldn't need backups. By discussing backups, we're already assuming this might happen. Unless you consider backups to protect only against theft or fire. Accidental deletion and corruption are also major factors.

> 3) Have all your sync'd machines get the deletion.

That's what the system is designed to do, so that's a given.

> 4) Have Dropbox's file revision history go wonky on their side.

There well be one error that leads to both file revision history going wonky and the introduction of file corruption or deletion.

I'm not having a go at Dropbox, it works as expected. But backups need to be independent, not heavily integrated. Otherwise what you get is some kind of pseudo-backup that won't cut it in particular, relatively common failure modes.

It certainly isn't "one heck of a failure". It's one failure.

The clients hold copies of old revisions for three days. That's a healthy margin to find the corruption in case of the dropbox servers failing terribly.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact