DISASTER RECOVERY 
JOURNAL

P. O. Box 510110
St. Louis, MO 63151
(314) 894-0276 
Fax: (314) 894-7474
Internet www.drj.com 
E-mail drj@drj.com

PUBLISHER &
EDITOR-IN-CHIEF
Richard L. Arnold, CBCP
richard@drj.com

SENIOR EDITOR
Janette Ballman
janette@drj.com

MANAGING EDITOR
Jon Seals
jon@drj.com

COPY EDITORS
Richard Sandhofer
richards@drj.com
Pamela Clifton
pamelaclifton@hotmail.com

ADVERTISING 
Robert Arnold
bob@drj.com

_____________

Corporate

President/CEO
Richard L. Arnold, CBCP
richard@drj.com

Vice President 
Robert Arnold
bob@drj.com

CONFERENCE COORDINATOR
Patti Fitzgerald, CBCP
patti@drj.com

CONFERENCE REGISTRAR
Merce Knese
mercedes@drj.com

CIRCULATION
Laura Baugh
laurab@drj.com

INTERNATIONAL
CONTACTS
England: Thom Hetherington
Business Continuity 
Phone: 0161-237-1007
thomh@tempus.demon.co.uk

Australia: Anthony J. Harvey
Journal of Business Continuity
Phone: 0011-613-953-0055-8
fax: 0011-613-953-0528
sector@notability.com.au

Japan: Shinji Hosotsubo
Quake Japan Co., Ltd.
Phone: 03-3215-2880
fax: 03-3215-2881

Brazil: Jose Carlos Ferreira
Disaster Recovery Mercosul
Phone: 55 11 3666-9506
conc2000@uol.com.br
www.drms.com.br

Click Here for a Printable Version

An Interview With Robert Burns
of EverGreen Data Continuity, Inc.

By ELIZABETH M. FARRARINI

Storage infrastructures have started to resemble the layers of a perpetually growing onion. The good stuff – data – resides at the core. However, before you can get to it, you have to unwrap each layer. You have storage devices, systems that support these devices, networks that support systems, applications that sit on the systems, and business units that need the systems. Robert Burns, president and founder of EverGreen Data Continuity, Inc., Newbury, Mass., says, “You can’t improve your storage infrastructure unless you understand every one of the layers that make up your infrastructure.”
Burns recently provided a glimpse at how he conducts these assessments, what holes they’ve uncovered, and how he’d solve certain problems.

Farrarini: Where do organizations fall short when it comes to doing their own assessments?
Burns: Most companies don’t have the tools to evaluate their storage environments. Most IT professionals don’t understand all of the issues. They just look at how much data they have and guess at what they’re going to need. People just don’t manage their data.
For example, our assessment usually shows that less than half of the data on dedicated servers is active. Some customers have bought storage management tools and never used them.
Management thought these tools would be a good idea, but the systems administrators thought otherwise.

Farrarini: Can you explain the methodology you use for an assessment?
Burns: To provide better data protection, you need to look at the storage problem. That’s what we do. We breakdown a customer’s storage infrastructure into modules, such as storage management, and, within each module, rate their practices against our 356 best practices for storage management.
For example, the storage management module looks at backup and recovery practices, high availability, storage growth capability, storage management performance concerning the network, and disaster preparedness.
Say a customer had a recovery time of two hours. We might rate them from a one to five (strong) how they meet this recovery time as compared to our best practice.
We’ll also provide an explanation of the best practice. Take backup. We’ll describe our best practice for doing full backups. We’ll explain how they are doing with backups relative to, for example, a full backup, which would allow them to recover in the time objective they’ve defined.

Farrarini: What’s the real meat of an assessment?
Burns: It has to be the design architecture phase, which may or may not happen.
Let me clarify. If a customer doesn’t agree with the findings in the current storage infrastructure part of our assessment or doesn’t have the budget for it, then we don’t want to recommend a new storage architecture.
If a customer opts for it, then we’ll dig deep into what the customer has. By looking at the enterprise storage environment, we can start to develop recovery criteria based on what they’ve defined by for their environment. The criteria deal with what’s needed for storage scalability.
From here, we can develop the architecture. We really get into why SANs make sense. We’ve developed evaluation criteria for all the functions they’ll require in a new storage architecture, as well the way various classes of products stack up against each other.

Farrarini: Since your assessment of a customer’s storage infrastructure covers many areas, can you describe how you go about getting all of the information you need?
Burns: The trick includes putting together a hierarchy of sources. We begin by having a two-hour to a four-hour discussion with the CIO and the top managers. We learn what they expect from the business critical applications, such as recovery objectives.
Next, we like to speak with their internal customers, usually business unit leaders, to get an understanding of their needs.
We speak with application managers, followed by individuals running the data centers. We break the data center group into platforms, such as Unix and Windows NT.
We next talk to the system architects responsible for the design of the storage. Of course, we also include the operations personnel who run the help desk.

Farrarini: Do you find any inconsistencies among the way each group perceives the storage environment? Let me add, do CIOs really know their storage environment?
Burns: Plenty of inconsistencies! That’s why we interview these groups separately. Each group seems to have its own perceptions of the way things are.
The biggest inconsistency occurs between what top management thinks is happening versus what the architects say the systems will do, and what the operations personnel have to cope with everyday.
Most of the time, CIOs don’t know a lot about what works and what doesn’t work in their storage environment. These executives, however, prefer to focus on the storage cost implications to the overall organization.

Farrarini: You mentioned that your customers really don’t have a good handle on how their data is being used. Given this scenario, how do you get them to give you this information?
Burns: The hardest thing to find out is what data they have, and how much they have. For example, “How much data do you backup weekly?” may seem like an easy question to answer. It’s not. In fact, we tend to flag this area as the most serious issue we have.
We give them a table with 13 columns. We ask for a server’s RAID levels, operating systems, backup frequency, and number of users, as well as other information. We also want to know the types of backups and when they occur.
One difficulty is that not all systems are backed up the same way. Another problem is that it’s hard to get this information from reporting part of backup software.
We can spend several weeks prying this information from the customer. Most of the time, they don’t have the information they say they do.

Farrarini: When it comes to storage policies and procedures, such as backup and recovery, where are your customers usually the weakest?
Burns: You said it. Backup and recovery! Most companies have adequate backup procedures. They don’t have a good handle on how to handle failures that occur in their backup process. In some cases, the person doing the backups doesn’t have a good methodology for how to recover the data if something goes wrong.
Another problem is that some organizations have backup schedules that don’t complement the recovery objectives. For example, most organizations do nightly backups. But if you have a recovery time of two hours, and you have a failure, you can lose 23 hours worth of data because you’re not backing up every two hours. That’s why in the assessment we take a good look at how people are doing things.

Farrarini: Prior to doing the assessment, where are most of your customers with disaster recovery?
Burns: The large organizations have out-of-date disaster recovery plans. Many midsize organizations don’t have a plan. Organizations don’t test what plan they have.
Financial organizations, on the other hand, are the exception. Federal law mandates these organizations test their plans once a year. However, most of this testing concerns mainframe systems. Most organizations are still trying to figure how best to handle disaster recovery for complex distributed system environments.

Farrarini: If a large company isn’t prepared for disaster recovery, then what preventative measures do you recommend for small to midsize companies?
Burns: Organizations with either no IT department or a small centralized one might want to consider outsourcing the management of their IT infrastructures to managed service providers. These operations have facilities with excellent disaster recovery capabilities – such as redundant power supplies, and redundant generators.
Another alternative would be to outsource the backups to a local service provider that specializes in disk-to-disk backups and disaster recovery. Before going this route, the organization needs to consider if a recovery can take place within an acceptable time. Does the organization have to wait for the service provider to ship a tape?

Farrarini: If a customer had a recovery goal of zero downtime, what would you recommend?
Burns: You probably should be mirroring your data to a local facility and an off-site facility. These should be high availability applications only – and both applications should be sitting on each site. You also need to have some sort of a heartbeat monitoring system tied between the two sites. If the second site has to kick in, the data has to be in the same format as the data in the primary system.

Farrarini: Apart from zero downtime, a lot of companies are considering mirroring to an offsite location, perhaps a third-party site? What are some of recommendations you make to customers about mirroring?
Burns: Since a lot of our customers have more than one site, we tend to recommend they mirror or replicate data to one of their sites rather than go with a third-party. That’s if the customer is equipped to do it.
We recommend double mirroring. The first mirror creates operational data to use if your disks go down. The mirroring occurs on-site. The second mirror takes place at an off-site location owned by the organization. This mirror gets used if a disaster occurs.
The two facilities should be between 20 to 30 miles away so you don’t have a regional power problem. The second site should have a data center that can be used for processing.
The pecking order for application processing priority has to be clearly defined. If the local site goes down, the computers at the other site can be cut over to handle the high priority applications. The low priority applications are either shutdown or reduced during the outage.

Farrarini: As a former manager of large data centers, you lived through both centralized and distributed control of storage. Where’s the best place to put storage?
Burns: For the past 12 years, I’ve been telling everyone this: storage ought to be in the network. A SAN puts storage in the network. Shared storage in the network architecture provides the most direct route for getting at your data. Storage should be within the site that owns it.
I’m not in favor of moving your primary storage into a co-located facility managed by someone else. I’d want control over my data.

Farrarini: Before deploying an enterprise SAN, what changes should an organization make to its storage infrastructure, especially in the data center?
Burns: Until you start consolidating your facilities, your SAN architecture will be all over the place. We recommend centralizing as much as possible to minimize bandwidth needs. Put as many applications as you can into those servers. Also, bring as many of those servers into one standard facility, rather than scattering them everywhere. Use the power of an Internet portal to access servers in a common site.

Farrarini: Although you folks don’t get into how a customer purchases storage, what recommendations would you suggest for the way an organization goes about it?
Burns: We like the idea of centralizing purchases, as long as it’s done intelligently. Ever wonder why a lot of data centers have one of everything?
For example, applications engineers may recommend something that doesn’t fit with what the data center folks would use. Any type of a purchasing task force, however, has to have the knowledge and understanding of the problems they are trying collectively to solve. Otherwise, it’s a failure.

Elizabeth Farrarini is a freelance writer based in Boston, Mass.

To comment on this article, go to 1502-ask at www.drj.com/feedback.