Apr
22

Thinking about Dependence and Connectivity While Recovering

Thinking about Dependence and Connectivity While Recovering

April 22
By

Backup and disaster recovery can sound fairly basic. All you need to do is take some backups then recover them if something fails, right? Well, on a fundamental level, yes, that’s what you’re doing. But here are at least two things that might elude IT admins attempting to recover in an emergency: connectivity and dependencies.

Determining what configuration needs you’ll have before anything goes wrong is essential because networking involves layers of dependency. If you personally set up a network you’re hoping to protect against failures, then you probably know which systems need to be operational in order for the rest of the equipment to function (assuming you’ve carefully documented). Getting a piece of hardware up and running—even as a temporary VM—involves making sure all equipment in the network, virtual or physical, can communicate with each other.

You’ve got to think about all different scenarios when it comes to recovery. If your Exchange server fails and you’ve prepared an instance of StorageCraft HeadStart Restore ahead of time, you can failover as a VM on another server, but will this server be able to talk to the domain controller? What else does the failed server rely on to be fully functional? It’s great that you can get a server back up and running, but it’s essentially useless if it doesn’t talk to the rest of your network. Does the software set up everything for you? No, it doesn’t, so it’s up to you.

The best way to recall how each client’s network map is to look at a reference sheet you created ahead of time. This means that if you’re building a network, you need to document everything as you go. If you’ve just been hired to handle a client that already has a network built, understanding how the network is set up should be one of your first tasks. Write down everything you need, from which equipment is connected to which, to what equipment is dependent on which other equipment, all the way to network settings and IP addresses. You never know what you’ll need, so write it all down.

Along with writing things down, one helpful way to visualize network dependencies and to keep IP addresses and settings in one place is to draw a map or create a network map online using free tools like draw.io and others. Mapping and documenting everything in one place keeps each client’s critical network information consolidated so that in an emergency, you’ve got all you need on one easy-to-read sheet. This makes it simple to know what you need to do when something fails.

Once you’ve got all the info you need for each client, keep it all together in a few locations. If any client has a failure or large issue, you need to be ready to look at your network map and resolve anything that happens without struggling to remember what goes where and what needs which settings. It’s ultimately about keeping information organized and accessible.

Remember, of course, that your own systems aren’t immune to failure. As our partner Guy Baroan of Baroan Technologies explains in our ebook: Five Lessons about Disaster Recovery from Hurricane Sandy, keeping everything in digital-only format is a mistake. If you and your clients experience the same area disaster, you might not have the documentation you need to get them back online if you keep everything digitally. Keep physical copies at your office, but also keep another physical copy at a secondary location just in case. Think about what will happen if your data is lost as well.

Think carefully about configuration needs because network settings can be tricky if you’re not ready ahead of time. If you’re not sure what they need to be, you’ll have to waste time figuring them out and you’ll create more downtime instead of reducing it like you’re supposed to. Clients count on you, don’t waste their time when they need it the most.

Photo Credit: ShieldConnectors via Compfight cc