Maybe this is more a 'note to self' than anything else. No matter how much you think you won't need a database when you drop it, just make a backup before you do anyway.

Today for example, there is a server which has 2 environments on it: dev.example.com and staging.example.com. The client said they had pending changes on staging. We knew the client was only working on one environment.

So I thought it was safe to copy the staging environment over to dev, and I did!

Shortly after, an email comes across to the effect of, "Does anyone know why staging (dev.example.com) is different than it was yesterday?"

Yes, I do! =/

Long story short, it worked out since a lot of the database work was already on production. It just would have been a LOT easier and less stressful if I would have ran a backup before I overwrote dev.

A code snippet for mysqldump should be appropriate yes?

$ mysqldump -u<username> -p<password> <dbname> > mybackup-yyyymmdd.sql

You can also omit the password, but leave the -p. This will prompt you for a password when you enter the command. A good reason to do this is so your mysql password is not in your shell history.

Note the naming convention of the backup file. Naming your backup with the yymmdd format is excellent for having backups of a single database list in chronological order in the file system.

Here's how you would load up that db file:

$ mysql -u<username> -p <dbname> < mybackup-yyyymmdd.sql 

Notice we use the more secure method here as we do not put the password itself in the command. Once you press enter, you will be prompted for a password.