> I think this bug should be considered completely separately from how unwise it is to use a cloud service as the sole storage of important files.YES: from DropBox's point of view - this is a serious bug even ignoring what other actions the users have/not taken to protect their data.
And NO: this sort of thing is one of the key reasons not to use such a service as a sole backup - linking the two when trying to educate users on the importance of thinking about data safety, so we can't separate the two as one is important when hammering the other point home...
> Even for files that are deleted intentionally and unambiguously by the user, I'm astonished that Dropbox actually deletes the files at the end of the 30-day restore window. I would expect them to keep the files for some multiple of the publicly-stated restore deadline
That would cause significant consternation in some areas. If I explicitly delete a file I might explicitly want it gone within the stated window and no later and would therefore be unhappy if I found the data still available (even if I had properly encrypted it before it touched the cloud service so noone else could read it).
> For files that aren't intentionally deleted by the user but are "de-synced",
I definitely agree there - it sounds like that process needs some transactional workflow wrapped around it so that:
1. Client and server don't do anything until they've both agreed what to do (then they can both go away and do it even if the connection drops, safe in the knowledge that the action is correct).
2. The client and server record what has been agreed as part of that transaction protected process, so in the case of an unclean stop during the process it can be resumed/retried.
3. Some process may need to be in place for one side rolling back if the other detects a failure applying the agreed actions.
Of course this is a fair bit of work for something that won't happen often, particularly when you consider that there might be more than one active connection to a set of files at any given time so it might not be a simple two-way merge operation, so DB may have other priorities - but the bad PR from it happening and not being cleanly dealt with is something that they need to consider if making that sort of decision.
> "The user should have kept multiple redundant copies" is not an excuse for a poorly managed online backup service
Agreed. But "the single backup service failed" is similarly not something that is going to encourage me to have sympathy for the user!
Sync services are excellent secondary backups, and they satisfy the "off site" requirement that a great many home and small-office users neglect (I know people who worked for a small company which died because the backups were in the same building as the active data so one fire took out the lot), but no one should trust them as their only backup. I even recommend against multiple sync services as your only backups as that in itself can cause problems (when bugs or other peculiarities from one interact badly with similar behaviours in another).
Using just a sync service means you have no off-line (or even semi-offline) backup, which is as bad as not having any off-site copies.
Of course getting this involves educating users as to the risks they are taking, which is a point notoriously difficult to get across, so while I don't expect a service like DB to be perfectly bug free (and therefore wouldn't trust it as an only backup) I think such services need to help the education process by being a little less indigenous about the safety issue and making sure their users know that an accidental delete will be propagated everywhere and be unrecoverable after a time. This will never happen though: "please use some other backup option too in case ours goes wrong" is not a sentiment marketing departments or investors will want to see publicly stated!