Support Desk - Deleting Dangers


Rocco at the Support Desk

There are some things the hardy folks on the frontline of Compose can't control. Specifically you. And if not you, someone like you. People can't help it but they are inextricably drawn to red things like the delete database button. It's big and red and demands pressing apparently. We've concluded this from an uptick in accidental database deletions around MongoDB and we'd like to help you not get into that situation.

It can happen for all sorts of reasons. Sometimes, you press delete and then realise you really needed the data. Sometimes, it's a miscommunication between members of the team over which database to delete. Sometimes, it's untested changes in applications going down paths it shouldn't and triggering maintenance routines and sometimes it's just finger trouble in the Mongo shell.

Whatever the cause, if you delete a database and then suddenly realise that you actually needed it you may think everything's backed up so it's just a matter of restoring it and we'll be all fine. But it's not quite that simple.

When you create a Compose MongoDB deployment, it's that deployment which is backed up as a single entity. Creating databases within that deployment doesn't change this; the database is part of the deployment and is backed up as part of the deployment. That means there's no simple path to restoring a single database.

One option is to restore the deployment. Restoring on Compose MongoDB creates a new deployment to restore into so it won't affect your running databases. Then, you can use the import tool to pull data from the newly restored deployment's databases to repopulate the deleted database. Once you are done, you can delete to restored deployment and carry on.

Be extra careful when deleting deployments though. If you delete a deployment, the entire deployment, backups and all, goes with it and you'll have nowhere to restore from. You may want to consider downloading the last backup of your deployment before you delete it to ensure you do have a "from" to restore from if it turns out you shouldn't have deleted it.

If you want to be sure of having databases that can be independently restored without affecting other databases, you'll want to consider the option of having a database per deployment. This means the deployment and database are effectively the same entity and restoring the deployment's backup will only restore that database.

Most of all though, be sure that you don't need the data in a database or a deployment before you delete either. The Compose UI requires reauthentication and reselecting the deletion and prompts "Are you sure?" before it lets a delete take place. We'll try our best to sort you out if you suddenly find you've deleted an important database by accident, but the best course of action it to practice safe deleting.

Dj Walker-Morgan
Dj Walker-Morgan was Compose's resident Content Curator, and has been both a developer and writer since Apples came in II flavors and Commodores had Pets. Love this article? Head over to Dj Walker-Morgan’s author page to keep reading.

Conquer the Data Layer

Spend your time developing apps, not managing databases.