Last month DO rebooted my droplet (I received an email notice of this), it came back with all my config files filled with just @@@@'s... They were not helpful at all, after 5 emails they offered to help migrate leftover data to a new droplet but there was nothing that wasn't in my backups, my site was down for a day.
Yeah, I got turned off DO when a bunch of data was deleted when I resized a node. My fault for not backing up first, but the support folks at DO didn’t have to be quite so snarky about it.
Fly told me in 7-days they would automatically update my redis database. My plan was to manually update it that weekend. 3 days later, I get an alert that they migrated the db early. b/c I didn't have storage enabled, all data was gone.
I'd much rather they figured out how to fix their sync service - or at least let me actually delete everything on it and start again! I still get temporary containers coming back months after I have deleted them!
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.
The behavior sounds considered; the web site doesn't describe it to the user.
How about if the Destroy dialog read something like:
This is irreversible. We will destroy your droplet and all associated backups immediately. We will keep a snapshot that you can use to recover your droplet; you can disable this below.
[v] Scrub data - [etc.]
[v] Temporary snapshot - this will keep a snapshot that you can use to recreate your droplet. This snapshot will be destroyed in 24 hours.
and the Select Image list showed something like:
Destroyed Droplets
chef.nl-haa1.infr.as f… — automatically deleted at 2014-04-01 09:25 UTC
Same exact thing happened to me. Out of nowhere, my (paid) app started failing. It was only after signing in did I see that the entire postgres database had been removed. No warning that this was going to happen, no ability to recover a backup. Just... deleted.
Not the end of the world for me, because 95% of the data I had in there had already been processed, but I did lose some. Complete joke of a service.
To add to your fears I had catastrophic syncing issues last few. Stupidly enough I had turned off local backups thinking Google would be better. 10gb of design files gone.
I still haven't worked out what happened but there where 5 computers syncing the files at work, something got muddled and deleted everything off all the computers at once. All I know for sure is somehow they where modified by a person who wasn't at work that day (and hence not on there PC). They where then deleted, but not available in the online trash, gone off all computers but not moved to the local trash as the forums so it should of, and all history had disappeared from the online drive.
They still appeared how ever if I did a search for them, you just couldn't navigate to them or find them in through any other part of the UI. So I did manage to zip them all up and get my data back.
Anyway lesson learned, and for me its dropbox and local backups from now on. All trust lost for me. I have no idea if it was syncing, an error in the cloud, or someone in the office, but yeah total loss of trust for me.
If it was an ex-admin he might have deleted all the backups also. But they should be able to tell this publicly, otherwise it's similar to recent case where the newbie deleted the prod DB without any backup.
I was notified of the potential data loss and checked my data on the 'personalized web page.' Of the 12,000 files that may have been affected, I found only a subfolder of a few dozen photos that may've been removed.
The problem is that when I clicked 'restore all' from within the subfolder, Dropbox restored all 12,000 files rather than just the files within the folder.
Note to DB's UX team: when you place a Restore All checkbox above the lefthand file selection column, it means 'select and restore all files on the page', not 'lift the roof off my house and dump in all the shit I spent months decluttering.'
reply