You should always keep detailed documentation on each of your servers as part of your DR scenario.This document will become your holy grail in case you ever have to recover your servers.
True story: Our BI team had 3 servers, and one of them was 2 weeks away from being retired. Suddenly, in the middle of the afternoon, the server went off-line. I contact our infrastructure team, and ask them to take a peek into the server itself, in the server room, and tell me what happen. After 10 harrowing minutes later, they return and deliver the grisly news: the motherboard had fried, and the box was dead. Lucky for me I had current backups of all the databases, but not of the replication Publications. Those can be rebuilt, sure, but it would have saved me a bunch of time if I had those pubs scripted out.
Again, your documentation should be thorough. Here’s a few things that should be part of your documentation:
- What are my driver letters?
- How much disk space do I have?
- Who are all my local admins?
- What are my server IPs?
- If using SQL Replication, save your publication scripts
- etc….
Sure, you can have a lot of this information from database backups. But always hope for the best, and plan for the worst!
For this post, this is the script we use to document the IP addresses for our server farm:
SELECT
CONNECTIONPROPERTY('net_transport') AS net_transport,
CONNECTIONPROPERTY('protocol_type') AS protocol_type,
CONNECTIONPROPERTY('auth_scheme') AS auth_scheme,
CONNECTIONPROPERTY('local_tcp_port') AS local_tcp_port,
CONNECTIONPROPERTY('client_net_address') AS client_net_address
In future posts, we’ll go into more details on our DR documentation strategy.