This morning you woke up with a terrible premonition – you were absolutely sure your most important production database server was going to crash today.
What would you do?
Here’s a quick list of places to start:
- Identify where the most recent backups are kept
- Make sure the backup schedule and frequency lines up with what the business wants
- Make sure the backups are getting offsite
- Make sure the monitoring software is watching this server, and sending me alerts
When was the last time you made a list like this and checked it twice? Do it this week, and schedule yourself a recurring task in your favorite to-do software to check this every quarter.
Because you’re not going to get these visions.
7 Comments. Leave new
I would also make sure that I had an up-to-date list of the server/application users – (preferably in an email distribution list) so I could inform them as soon as possible when the server falls over.
Great reminder !
Slightly different scenario, but when when we needed to restart our consolidated environment we didn’t have a clue who to inform. Aim for group emails,not individuals, they move too often.
Check to see when you last practiced a DR test and had updated documentation. And at multiple levels; hot and cold standbys, bare metal, geo. And if YOU got hit by the bus before it ran into the datacenter, who is your backup? No single point of failure in people, process, or technology.
BWAAA-HAAAA!!!!! Ironically, if you have to “check to see” for such a thing, then you’re doing it wrong. 😉
And make sure that someone else in the organization knows how to do everything you’re doing, or at least has enough documentation to figure it out.
It’s just not possible to have that kind of backup talent in many companies. Most companies don’t understand the need for even one person to know this never mind two. If folks care for the company that they work for, the best plan is to automate everything and document how to use the automation. Even with that, they still won’t be able to do everything because it’s not likely that someone else knows how to troubleshoot a production problem or long running query, etc, etc. The only way that can happen is if you happen to have the budget for two DBAs that know SQL Server at the system level and can double as monster developers that can also troubleshoot performance problems.
and… when did you check the last time if a backup actually can be restored?
wont be the first time that the coffee is getting cold because the backup actually isnt restoreable.