In the event of a disaster, IT teams often think of servers and storage, but forget about networks. Find out what you should document as part of your network DR plan.
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Step 2 of 2:
that were affected. A good set of network documentation can be extremely valuable in the event of a disaster.
What types of things should a DR team document as part of its network disaster recovery plan? Network documentation best practices should start with noting the configuration settings for every piece of networking hardware in the data center.
Disaster recovery teams should make sure to document and back up the configuration settings that the network routers use. Likewise, document which ports are open on firewalls as well as any rules that might be configured on the device.
Document device changes for easier replacement
In addition to documenting the settings, it is also a good idea to create screen captures of each of a device's configuration screens. That way, if the organization has to replace a device and finds that it won't work properly, you might be able to compare screen captures with the new device's configuration to see what is different between the two.
Many appliances will allow users to export the configuration to an XML file or some other file format, but other appliances have no such mechanism. Even if you can export the device settings, it's a good idea to have a written copy of those settings. If a disaster wiped out a data center, then appliance configuration files might also be lost. This would make it impossible to restore a saved configuration to a new appliance. In such a situation, a written copy of the configuration settings for reference would be the best option for configuring the new appliance.
It's also possible that the new appliance is running a higher firmware version than the device that it is replacing -- or is an entirely different model. In that case, the device might be unable to import the configuration file. Again, having a written document containing the previous settings is the best option for setting up the new appliance.
Include firmware versions in your network DR documentation
As DR teams create a network disaster recovery plan, best practices include documenting the firmware version that's in use on each of the hardware appliances. It can also be helpful to download a copy of the firmware from the appliance manufacturer's website.
When replacing existing appliances, the new appliance is almost certain to be running a different firmware version from the previous one. Knowing the failed appliance's firmware version and having a copy of that firmware can make it easier to set up the new appliance. After all, depending on the scope of the damage, there might not be a way of checking the old appliance's firmware version in the absence of proper network documentation.
If the new appliance ships with an older firmware version, then it needs to be brought up to the same firmware version in use by the organization. Remember, firmware updates often resolve bugs or address security vulnerabilities. In addition, some of the configuration options in use on the old appliance might not exist in the older firmware version. Even if such features did exist as part of a prior firmware version, the features might have worked differently in the past.
If the new appliance is running a newer firmware release than what you had been using previously, there might be no choice but to use the newer firmware version, since appliances typically do not support firmware downgrades.
A network diagram of the data center is a key part of a disaster recovery plan.
For example, imagine that a router in a data center is struck by lightning. If that were to happen, the configuration documentation could help to configure the replacement unit. However, unless the replacement router is identical to the old one, IT teams might have a tough time figuring out which network cables should be plugged into each port.
This is where a good network diagram comes into play. Sure, it is possible to figure out the appropriate cable arrangement without having a network diagram, but when the goal is to get back online as quickly as possible, a well-annotated diagram will help do just that.
Another network documentation best practice is to record the contact information for anyone who might be able to provide assistance in the event of an emergency. Documented contact information should include the following:
Employees in the IT department.
Relevant vendors the organization works with.
Technical support contact numbers for the hardware and software manufacturers.
Contact information for any stakeholders within the organization who need to be notified of the outage.
Keep detailed hardware product information
Other network documentation best practices include maintaining detailed information about each piece of hardware in the data center. While it is important to document information such as an appliance's make, model, firmware version and serial number, there is additional documentation that might be needed for swift recovery.
Depending on the scale of the disaster, a recovery team could end up having to call technical support, a warranty department or even an insurance company. The information needed on hand is going to vary depending on where the organization ends up calling.
For example, if an organization has to call a software publisher for support, it might need to have the license information handy, as well as the vital statistics for the hardware and the OS that the software is running on. If it has purchased a support agreement, then it will need that information as well.
If, on the other hand, the organization is trying to get support for a hardware appliance, then it might need the appliance's purchase date and the support contract number. The vendor will probably also want to know whether the appliance is still under warranty.
Regardless of whether the incident involves hardware, software or some combination of the two, the goal is to get things back to normal as quickly as possible. Having all the relevant information in one place will go a long way toward accomplishing that goal. No one wants to have to waste valuable time trying to find a serial number sticker on the back of a server or a license key that is stashed in a drawer somewhere.
In addition to creating the necessary network documentation, organizations must make sure to have a printed copy available, just in case a disaster renders the data inaccessible.
