Something doesn't add up. The user who wrote the report did not request that the destroyed droplet be recovered. The existence of lingering data was disclosed by traces which appeared in a brand new droplet. The only reason I can come up with for why that would ever happen is that you are re-using droplets, perhaps because erasing and resetting a few files is cheaper and faster than provisioning a brand new instance. If this is indeed the case, then what you are suggesting -- namely, that what looks like sloppiness is in fact conscious, customer-driven product design -- is completely false, because it means that the droplet recovery feature is available only in those cases where the customer did not create a new droplet after destroying the droplet she would now like to recover. I guess that this is why you were "able to recover almost everyone's droplets" after an attack, but not everyone's. The "temporary snapshot" feature is not actually a feature, or even a "mechanism" -- it's a bug, just one with a side-effect is occasionally positive.