Hacker Newsnew | comments | ask | jobs | submitlogin
davidu 1101 days ago | link | parent

It keeps file revisions server-side. So you'd have to have one heck of a failure to find out:

1) Have all your nodes syncing at the same time and connected. 2) Introduce file corruption and deletion. 3) Have all your sync'd machines get the deletion. 4) Have Dropbox's file revision history go wonky on their side.



rlpb 1101 days ago | link

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

-----

Dylan16807 1101 days ago | link

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.

-----




Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: