> 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!
> 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
Very few (if any) users who explicitly delete a file want that file recoverable within 30 days but not after that. They either want the file recoverable for a much longer period of time or they want the deleted file to be irrecoverable immediately. For the latter option, Dropbox offers the ability to "permanently delete" files. It requires at least four clicks to accomplish, displays a warning, and is driven entirely via the website rather than through the Dropbox client.
Of course this is a fair bit of work for something that won't happen often
If you think about it, that sums up almost any robust back-up system you go to the effort of setting up, properly testing, and maintaining over time. For that matter, it applies to almost any insurance policy in any context.
I expect most of us would still agree that potential catastrophic damage if you're the unlucky one can justify spending the time/money/resources to set up proper back-ups and insurance, though, and surely this is the case if you're running a service where robust file handling is your major value proposition.
> If you think about it, that sums up almost any robust back-up system you go to the effort of setting up
Exactly, which is why people should think harder than they do about backups. You should make sure that you are not exposed to risk you don't want to be exposed to because someone else's development priorities differ from your point of view.
True data protection is unfortunately a complicated business and most people see the flashy presentations on services' sites and trust all is well without giving it a second thought.
While I agree it should be the service's responsibility to cover these eventualities, it is not good practise to assume that they do. You might misunderstand what they do and not see risk were it is present, they might have honest coding mistakes that cause problems down the line, there could be ineptitude anywhere down the line, and so forth. If you are paying for their service then you might legitimately expect to be covered by some for of insurance for loss in the event of it being caused by a problem in the code/infrastructure, but never assume that until being explicitly told it is present and you have read the small print, and don't ever assume this at all for a free/cheap service.
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!