How to Avoid Hardware/ Software Drift

I’ve been writing about the hidden hazards of do-it-yourself disaster recovery. One of these hazards is hardware/software drift. Since your disaster recovery site represents a working replica of the production environment, it will need to be maintained on an ongoing basis. There are several strategies for how hardware and software are provisioned for your DR site. The strategies you choose will determine the how much maintenance will be needed to keep your DR site running at an optimal level.

There are two main techniques for acquiring hardware for a disaster recovery site, although you may want to use a combination of both. One technique is to replace hardware (i.e. a server) that is no longer covered by warranty with new hardware and use the old hardware for disaster recovery. Another strategy is to buy or lease new equipment to use at the DR site.

How to Choose a Remote Colocation Site

Choosing a disaster recovery location is critical to the success of any DR project. One of the biggest mistakes that you can make is to choose a colocation site that is too close to your production site. It’s way too easy for a power grid failure to knock out both your primary and your colocation site if both sites are located in the same metropolitan area. (It happens!) But the challenge of in-house DR is that the technical team responsible for bringing your DR site online will need access to that site. This means that the approach and technology used to deliver a disaster recovery solution must be capable of remote activation. Learn more about remote activation in the nScaled white paper The 5 Things That Can Go Wrong With DIY Disaster Recovery: 5 Things That Can Go Wrong With DIY DR

The Hidden Hazards of SAN-to-SAN Replication

It might be tempting to create a “do-it-yourself” disaster recovery solution by purchasing additional hardware and installing it in a branch office or colocation facility. But creating an effective disaster recovery solution is a complex project and there are several unplanned costs and other hidden hazards associated with it. I’ll identify some of these hidden hazards over the next few weeks.

I’ll begin with SAN to SAN replication. Any SAN manufacturer with a clear understanding of storage space has some kind of SAN to SAN replication offer, but not all SAN to SAN replication is alike. When creating an effective DR solution, you have to make several architectural considerations for replicating data between production and DR, including virtualization, application specific agents and snapshot storage requirements.

Recovery-in-a-Cave

Just got done reading the funniest white paper ever, from our friends at Iron Mountain. It asks the question, “…what happens when the devastation is so fierce that it hits the backups too? Don’t panic.”

Don’t panic? Really? I think you damn well better panic – about your career. You stashed your backup tapes so close to your primary data center that they got clobbered by the same natural disaster? C’mon man! Better update that resume.

And while we’re at it, why on earth are you still using tape? Iron Mountain, whose business is storing tape, points out just how fragile tape is:

“…if tapes suffer major temperature fluctuations every night, they will weaken and become more likely to snap. When your staff fails to maintain drive heads’ cleanliness, or cleans equipment incorrectly, tapes may be more prone to breaking. To avoid such problems, know the cleaning cycle and storage conditions recommended by your vendor.”

Really?

Disco Stu has moved from Springfield to the world of backup and DR.

Earlier this week, eVault announced 4-hour recovery times for their mid-size business customers. This is one of those mind boggling announcements that gets a lot of us in the business saying, “Really?”

Because the thing is, in 2012, a 4-hour recovery time is terrible. They never explain if the 4-hour guarantee applies to any single system or an entire data center. In either case, eVault’s claim is just plain archaic.

For the sake of comparison, nScaled offers customers a 15-minute RTO for any single system, and a 2-hour RTO for an entire data center.

Boston Fire leads to customer failover

You may have read about the fire in Boston yesterday that took out power for a section of the city.

The power outage affected the Boston office one of our large disaster recovery customers. We protect 70 servers in 11 offices around the US for this customer.

Our support guys were up late last night, getting the customer failed over so they could keep working through the interruption, so I haven’t had a chance to get the detailed story from them. I’ll post again when I have more news.

Hazard Insurance

Clusters of tornados last week and this week in the US Midwest once again bring one’s thoughts to the issue of insurance.

There are undoubtedly many small and mid-size businesses in Harrisburg, IL that are hurting right now, having had their offices damaged or destroyed by the tornados that hit earlier this week.

You can bet that those businesses, or their landlords, have insurance on the office buildings. The people who work at the businesses probably have homeowners insurance on their homes. But you can also bet that most of the businesses didn’t have a disaster recovery plan for their business’ information systems and data. And that means that most will go out of business in the next year.

nScaled Closes Series A Investment

As you can imagine, we are very excited to announce that we just closed a $7M Series A round of financing!

We were able to raise the money on the strength of our vision and our 2011 results. nScaled was a pioneer in recovery-as-a-service (RaaS) three years ago, when no one know what the heck RaaS was and everyone thought disaster recovery was a boring market, dominated by goliaths like Sungard and IBM, catering exclusively to huge customers who could afford to spend millions of dollars every year for redundant capacity. nScaled is now a leader in the suddenly hot RaaS market, a market that now is getting plenty of attention from the analyst firms and the tech press.

Protecting Multi-tier Applications, Part II

Today, we’ll wrap up our look into how to protect multi-tier applications…

Multi-tier Server Protection 

In a multi-tier server environment, the quiescent state of a single server isn’t enough. In order to achieve a working and consistent application, the various servers that make up the entire application stack may need to be in a quiescent state across multiple servers, a term referred to as “cross-server application quiescence”. As an example, in a document management system where the database server and a file server are both present, it is often necessary for the database and file server to be recovered from virtually the same moment in time. In other cases, it may be better for the file server to have a more recent copy of the data than the database server but never the other way around. In the process of working with our customers, nScaled has experience working with many different types of multi-tier applications.

Protecting Multi-tier Applications

Our crack Services team has written a new technical solution brief about the pitfalls of doing DR for multi-tier applications. Seeing as how most apps these days are multi-tier, and those apps are usually the most critical to a business, figuring out how to backup or failover is paramount. We’ll serialize the tech brief for a few days here.

Protecting Multi-tier Applications

Overview