Remote-location disaster recovery risks

With multiple remote locations, there's often risk associated with disaster recovery policies and technologies. Learn about the challenges of remote-location disaster recovery.

Play now:
Download for later:

Remote-location disaster recovery risks

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As



Hello. My name is Karen Guglielmo, executive editor for, and I'd like to welcome you to today's expert podcast on remote-location disaster recovery pitfalls to avoid.

I'm joined today by Greg Schulz, founder of The StorageIO Group, a technology analyst firm providing services focused on IT storage, storage management, networking and related technologies and topics. Greg has worked with Unix, Windows, mainframes, OpenVMS and other hardware, network and software environments. He is the author of The Green and Virtual Data Center and Resilient Storage Networks and has contributed to other projects, including The Resilient Enterprise and Virtual Storage Redefined.

Welcome, Greg.

Schulz: Hello, Karen. Thanks for having me here today.

As I mentioned earlier, we're here today to talk about remote location DR pitfalls. I will spend the next eight-plus minutes asking Greg to answer a number of questions about today's topic. So Greg, let's get started.

 What are the biggest problems midmarket CIOs face when addressing remote-office disaster recovery? 
Schulz: Several different ones come to mind. One certainly is the awareness at that remote site, of that remote facility, of that remote office, that branch office -- of the various risks, the reasons why they need to be protected. So, there's the lack of awareness from the remote office. But then there is the various threat risks, the various challenges, the various regulations that apply outside of those traditional data centers to that remote office. Then you start to get into some of the technology issues. Is there enough network bandwidth to move the amount of data? How much data is out there? How much is changing? What are the different regulations about moving data from remote offices? For example, if you have a remote office that's in a different country, are there particular requirements, legislation that prohibits data movement from that facility to wherever you're moving the data to? So, there's the technology, there's the business, there are the different threat risks that have to be contended with.

How can midmarket CIOs reduce the risk of failure for DR at remote locations?
Schulz: Well, certainly having a plan, having a strategy, which means taking a look at conducting a business impact assessment, similar to understanding what the issues are at a localized-type environment. But understanding what is out there. Gaining insight, gaining management insight, getting control over that remote site -- as though it were a local-type environment. That might mean moving all the resources back to a central IT, but it might also mean just getting control, gaining control, implementing processes and procedures to facilitate that. But what it means, also, is leveraging the different technologies and techniques; eliminating points of failure; eliminating or countering threat risks; implementing security, implementing physical security, logical security; implementing regular backups, whether it's local at that remote site or bringing data back somewhere or sending it to a third party. It's leveraging different techniques to understand what the threat risks are and to be able to protect against those leveraged best practices for high availability, disaster recovery and so forth.

Some midmarket companies are using SaaS for remote backup. What issues should they be aware of when using this type of model? 
Schulz: Well first off, leveraging Software as a Service, managed services -- MSPs, cloud-based services, hosted-type services, in other words the facilities, the capability, the function, the services for leveraging somebody else to send your data to. I think it's a great fit for remote-type environments. Here's the reason why: Core IT should be an alternative to providing that service to that remote facility. If you think about it, from that remote-facility standpoint, your options are to send it to some other service. That service could be core IT. If core IT is equipped to provide that service on a cost-competitive basis, they should then be in contention for providing that. Otherwise, that's where leveraging the third parties comes into play.

But having said that, that illustrates the compatible, the coexistence nature of leveraging core IT as a service. But what it also points out is that whether you're leveraging core IT as that service, or leveraging a third party, make sure that you're taking steps to protect that data. Ironically, you send your data to that third party to be protected, but are you able to get the data back from that third party when you need it? Are you able to access it when you need it? Is that network going to allow you to get to that remote site to get the data? So what that means is taking steps. Leveraging the ability to have a localized copy so if you can't get to the remote [site], you can get to the local. What that remote is protecting is in case if you lose access to the local. But you still need to protect yourself if you can't get to the remote access and remote data. Certainly, [it's important to leverage] things like security, encryption, protection of the information that's being sent to that.

What about the costs for remote-location DR? What pitfalls should midmarket companies be aware of when budgeting for this?
Schulz: Well, costs become interesting in that one of the primary objectives many organizations [have for going] to that third party, that cloud, that managed service provider, that hosting facility, that Software as a Service, that backup service -- is for cost avoidance. It's a way of shifting costs, avoiding costs. Plus, most organizations aren't in the business of being in data protection or backing up data. So, it's leveraging somebody who specializes in that capability.

Where the hidden costs can come into play is: How much is going to be charged for extra capacity, to store the data on a monthly basis? How much extra will be charged for sending data over the network? How much extra will be charged, the hidden fees, for individual file restores or the à la carte, the add-on items? Such as, is there an extra fee for managing encryption keys? Is there an extra fee for providing a certain interface, whether it be NAS file-based, block-based, for supporting simple file copies or for supporting hosting of data for different access? So, understanding what are the different hidden fees, what are the different requirements and when will those fees come into effect.

 IP telephony and VoIP are known to help with DR and backup. Are there any drawbacks to using them for remote-location DR?
Schulz: Well, I need to give a little clarification here. IP telephony, Voice over IP are actually applications in themselves. So from the one standpoint, they support that communications aspect, to be able to notify, to help communicate what's taking place, what needs to be done. But in reality, they need to be protected and secured as well. When you think about Voice over IP, IP telephony, those resources, they need to be protected. Wherever those are being hosted from, whatever network services, they themselves need to be part of that protection plan. It's not just about protecting the data, it's about protecting the assets -- the physical network, the switches, the routers, the servers that are hosting the IP telephony, the Voice over IP, the voicemail systems. They need to be protected as well, as part of being an enabler. It's similar to the notion of virtualization. Virtualization can be used for consolidating servers, consolidating storage and networks. But also, virtualization can be used for enabling BC/DR. So what we have here is technology that can enable and facilitate. But how they're also used also means they need to be protected, they need to be included as part of that plan.

And on that note, that concludes today's podcast. Thanks again to Greg Schulz for speaking with us today and thank you all for listening. Have a great day!

Dig Deeper on Small-business infrastructure and operations