Nuked prod db today. Fortunatly we had backup.

Now I’m gonna change my pants

Just say you were running a test of the failover systems 😬

I always do a manual backup and test my SQL script against a copy of that backup on my dev system before doing anything on the live DB.

It costs time but already prevented the dirtying of quite some pants in the past...

Important question: Have you learned from your mistakes?

If not, let me spank that wet butt till you remember what you did wrong.

@Oktokolo well really depends on how much of a size the PROD DB is.. You probably won't be doing that if you have several dozen GBs of data inside..

@martengooz welcome to big boys world

@myss
We aren't using floppies anymore. Multiple GiB of data shouldn't scare you from doing it right.

From your arrogance it's obvious you've never handled db larger then 100 gigs, good luck and lemme know on how creating a "manual backup" to your localhost will go and how many things will be on fire after/during your first attempt 😉

And creating manual backups of prod on your local is nowhere near doing it right.

More important question? How’d you do it!? I once took down an entire hospitals network for 2 hours.

@myss
There are DBs that aren't too big to copy - and there are DBs not containing usefull data.
If you have backups, the database can be copied. If you don't have backups, testing on the live system is indeed fine as the data obviously is disposable...

P.S.:
I don't say, that copying databases over 100GiB is fun - only, that you better do it and test stuff somewhere else before throwing it at the production servers.
It may of course also be the staging server instead of your dev system (i just happen to have it all locally too).
You need to test restoring a backup from time to time anyways...