What you will learn in this tip: Remote offices or branch offices (ROBOs) have a number of issues to consider when dealing with disaster recovery (DR) for their location.
This article will provide a starting point for anyone facing the task of finding an offsite disaster recovery solution.
One of the most important issues that a remote or branch office faces is its dependency on a central recovery site. This means that the fate of the local office data may very well be out of the remote/branch site's control. So although the remote recovery site may be unharmed during a disaster, it can be adversely affected by an interruption to the central or main site. For example, say you have a remote site located in North Carolina, but your main site, which handles processing centrally, is in Washington, D.C. If Washington, D.C. is slammed with an ice storm and has a power outage, your processing will be affected even if the storm is miles away.
The optimal disaster recovery solution for a remote site is to be able to perform backups (and restores) independently from the main site and be prepared to function on its own. It is also advisable for the remote site to have a disaster recovery site of its own. Keep in mind that both hardware and software are needed at the secondary site in order to perform a restoration of data if needed.
Data transfer is a key consideration to address with remote sites. Some configurations are set up as a "hub and spoke." In this architecture a central point (hub) controls all the messages to outer locations (spokes) that are dependent on the central hub. Many off-site disaster recovery locations use this hub-and-spoke architecture to handle applications such as email. The main email server, located at the hub, receives and transmits external messages, and forwards these to the correct spoke. This allows the central location to control the flow of external data access. Organizations may have different reasons for this, such as reduction in hardware requirements or security. Under normal conditions a hub-and-spoke configuration may be satisfactory, but what happens when the "hub" is unavailable or not recovered? At the very least, one remote disaster recovery site must be configured as a "backup" hub. This requires reconfiguration of the spokes so that they now radiate from the revised architecture.
I know of a company that had to revamp its entire communication infrastructure because of its hub-and-spoke configuration. Major locations such as New York City and Boston were set up as hubs, and remote offices were set up as spokes. However, the company did not set up any backups for the hubs, and when a disaster hit, the communication hub in New York City was unavailable, and all the remote offices scrambled for connectivity.
Key offsite disaster recovery concepts
Some offsite disaster recovery locations may have a standalone IT infrastructure, which may or may not depend on a host or main location. That is, they process their own data and can recover it on their own. In this case, the remote site will most likely have a backup solution for their data, so they just require a separate site for restoration from the backup media. As in the case of communication, if the data is held at another location the access will be an issue. A communication link to transfer the data/voice/network communications must be in place.
But keep in mind that simply having data backup and restore software in place at your disaster recovery site may not be sufficient for your needs. I have seen organizations have three or more tape drives for their backups, but only have one drive at their recovery site. If they ever needed to perform data backup at the recovery site, they would have to perform the tasks sequentially, not concurrently. This process would greatly affect the backup/restore timeframes. Pay attention to the recovery time objectives (RTOs) of the applications. Another important factor is to ensure that the hardware such as tapes and drives are compatible and able to operate in both environments successfully.
Some off-site disaster recovery locations do not handle the processing and storing of their own data. In these configurations, they are dependent upon the availability of a more central IT processing location. If an incident occurs where the processing center is unavailable, the remote site may require manual procedures to continue operations. If the incident makes the remote site unavailable, the processing performed at the remote site must be moved elsewhere along with the data communication.
Location or desktop processing was described in each scenario above. An organization may have an infrastructure that allows for remote access. In this particular scenario, staff with laptops may be able to continue to communicate their data directly to the central site, whether they are at home, in a hotel or at their local coffee shop. The remote access may already have multiple definitions for connection options on the laptops, for this very situation.
Communication and data are the two key concepts a remote office or branch office must address for access, data backup and recovery. Without data communication, you are isolated and not connected to anyone. If you require data transfer from your remote location to a central location, make sure there are sufficient modes and structures for data transfer. Data that is not available when and where it's needed is of little value. It is also important to ensure that the speed of communication is comparable to the amount of data to be transferred.
Disaster recovery solutions for a ROBO should be able to handle data backup and restore capabilities.
Disaster recovery solutions for remote offices
Disaster recovery solutions for a ROBO should be able to handle data backup and restore capabilities. That means that they must have not only a hardware appliance to store backup media and software to execute the backup, but sufficient hardware and software to perform restores at a different location, with additional keys or licenses for restore software at a disaster recovery location. Recovery centers are expected to be able to operate independently if needed, and to complete data backup and restores at primary sites. One must think about ongoing processing, not simply being able to restore data, but operate for longer than 24 hours. That will depend on the amount of data that must be restored and the timeframe. As mentioned earlier, if a backup of data is simultaneous, the recovery may need to be simultaneous. The exception to this is, if the data to be restored can wait for the initial data restore, i.e., has a longer RTO.
Several vendors currently offer disaster recovery solutions. Two of the larger ones are 3PAR and i365 (a Seagate company), but be sure to research all options first. Find a vendor near you and one that will satisfy your DR needs. The cost depends on your data requirements and time to recover. The cheapest method is tape, and that may be a good solution for you, or you may opt for more expensive disaster recovery solutions. And keep in mind that although the "cloud" offers some interesting backup solutions, keep in mind the amount of data you require and the speed of the communication link.
About this author: Harvey Betan, CBCP, CBCV, AMBCI, MBA, is a certified business continuity planning consultant, with extensive experience in recovery of both technology and business functions. His career has spanned a dozen years in business continuity after a 15-year career as a senior manager in information technology.
This was first published in November 2010