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