Disaster recovery checklist for the network professional

In the tip titled The network professional’s guide to disaster recovery, I discussed how, as a network professional, you must “sell” the importance of the network in disaster recovery planning.
To assist the network professional in asking the right questions and considering the right topics, we have created the following checklist, broken down into four topical areas: General network considerations, LAN, WAN, and network infrastructure applications.
This information sponsored by TrainSignal. Checkout their Windows & Cisco Training!

General network considerations

· When preparing a DR plan, remember to take “partial disasters” into account. For example, if your Internet circuit is down for 48 hours but all other services are functional, what is your plan? Not all disasters include “total destruction of your primary data center.”
· Diagram your current network and identify network devices. What is the criticality of these devices? How do those devices fit into the business-impact studies that determine the criticality of company infrastructure?
· Assuming you have a DR network, how does it differ from your current network? Can it handle the load that will be put on it if a disaster occurs?
· Do you have adequate network documentation for the DR network? When a disaster occurs, everyone will be in a panic. Having proper documentation can be the difference between the success and failure of a disaster recovery.
· How often is your DR plan tested?
· Has proper network resiliency been taken into account for the production network? Think about dual power supplies, redundant network paths and redundant circuits. These network resiliencies may prevent you from having to declare a disaster in the first place.
· What about voice communications? Are you using VoIP?
· Implement a process whereby the DR plan is updated when any new network equipment is implemented or network changes are made. This will keep your DR plan always up to date.
· Make sure you patch and upgrade DR equipment, just as you do other network equipment.
· Don’t forget about network security when you have a disaster. No end user will put down “anti-virus software” as a critical need. You don’t want to get your DR network up after 24 hours of work only to have it brought down by a virus. You must think about security because users won’t.

This information sponsored by TrainSignal. Checkout their Windows & Cisco Training!

LAN

· How does the DR LAN network compare with the production network? You don’t want to have Catalyst 6500 switches on the production network and Catalyst 2950 switches on the DR network and try to throw the same amount of bandwidth at the DR network. You are setting yourself up for failure.
· Are the LAN network pipes (Ethernet links) the same size?
· Do you have backups of the network configuration files for all devices?

WAN

· How does the DR WAN network compare with the production network?
· Are the bandwidth and QoS settings the same?
· Have any tests been performed to check the throughput of the DR network?
· Can the routers handle the same amount of throughput as the production routers?
· How do your users get to the DR network in the event of a catastrophe? Routing? DNS?
· Does the DR network have the same security as the primary network? Firewalls? AV? IPS? Internet DMZ?
· Is the same Internet access available on the DR network as on the primary network? What about Internet security add-ons such as content filtering? Proxy servers? Caching servers?
· What would you do if your WAN provider was also affected by the disaster? You could consider having a DR WAN through a different carrier or just put your DR site off of a different POP with your existing carrier.

This information sponsored by TrainSignal. Checkout their Windows & Cisco Training!

Network infrastructure applications

· Does your DR plan include a DHCP server?
· DNS Server?
· Does your DR plan include other critical network services such as WINS, FTP and Windows AD?
· Are there network devices that require certain network services to run? For example, some Wyse Winterm devices use DHCP and are then directed to a TFTP server to download their configuration file. You must take into account less-important services such as this because these are often the ones that come back to haunt you.
· What other network infrastructure applications are in use on your network? Have these been taken into account in the DR plan?

Please keep in mind that this is not to be considered a complete IT DR checklist. It relates only to DR and the network. In other words, this checklist is for the network professional who is thinking about how the network and DR are related.