Written by Steve Gruber
Throughout my 25 years in the Business Continuity/Disaster Recovery industry, I have never heard so much noise. Talk about an information overload. It seems that in the recent past, it was much easier to steer customers toward strategies and solutions that met their backup and recovery needs at an acceptable price tag.
Now, today – between the cloud buzz, software solutions, and various appliances being served up – the noise and confusion is heavily compounded. Couple these offerings with the constant parade of disruptive technologies, and it’s enough to cause a headache.
Based on my experience, it’s time to revert back to the basics, especially for those organizations that have not yet begun to idealize or test their recovery strategy. Today, many of our largest customers that perform their DR tests with us are still leveraging simple tape-based backup and recovery solutions. Therefore, tape is not dead and, on the contrary, is very much alive.
Some of our customers have begun exploring other solutions; including cloud-based offerings and a hybrid approach to backup and recovery. Others have jumped fully into the cloud, only to somewhat retreat when 1) they are hit with heavy data egress charges for pulling back their data, or 2) they have experienced the complexity of full-system restores in the cloud.
Realistically, there is no perfect solution for every computing platform you support today. Instead, there are many companies trying to convince you that they have perfected the latest and greatest solution to take care of your backup and recovery needs.
My advice – put your toe in the water with RES-Q™ Services and, based on our firsthand experience assisting clients with their DR testing, let us provide you with the opportunity to see firsthand, with no obligation, what technology could be the right choice for you.
As a Disaster Recovery professional, who has been in the Business Continuity industry for the past 24 years, you come across a product or technology that’s a real game changer every now and then. Let me tell you, that is exactly what Veeam is to the Virtual Server world, a major league game changer.
15 years ago when someone spoke of requiring HA or needed immediate recovery of their Intel server environment, there was one path and that was primarily Double-Take. Today the highway leads to Veeam for its versatility and functionality, not to mention ease of use. As one of their tag line references: “It just works”, and that’s exactly what we have witnessed time after time with our various customers.
As a software technology built from the ground-up for the Virtual Server world, Veeam is robust enough to handle just about anything you can throw at it and still gets the data backup and replication job done. Its ease of use coupled with its Cloud Connect feature can have you backing-up locally and replicating data to any number of Veeam Cloud Connect host partners at a DC location and price point of your choosing in no time. You can even find Veeam Cloud Connect partners who already have the recovery and server infrastructure in place so you can have a complete and affordable recovery solution that goes well beyond pushing data to the cloud. Now that is exactly what intrigued me, a real recovery solution that’s testable and takes care of your critical virtual system environment when disaster strikes.
Reach out to your peers and friends in the industry and you will see why Veeam now has over 155,000 customers protecting over 9.1 Million VMs.
Veeam on friends!
How do I test? Let me count the ways…
When most customers think of a DR Test, their first thought seems to be, “We must test as if we are experiencing a disaster.” Although this approach is the most common, it is not necessarily the best. While testing certainly should be a time to prepare for the worst-case scenario, it is also a good time to understand the Who, What, When, and Where of the actual Disaster Recovery strategy. Understanding these basics will not only help you test more efficiently, but more importantly, it will help you recover in the event of an actual disaster.
Why do we care about the “who” in testing for DR? Many companies make the mistake of assuming that every team member will be available to fill his or her role during a disaster, when in reality, resources will most likely be limited. I can think of two examples that should serve as lessons to all.
The first is the most recent—Hurricane Sandy. While I was working for a different DR Service Provider, a customer declared a disaster, only to discover upon arrival at the Recovery Center that their System Admin for a particular platform was trapped at home by flood waters. The customer was left scrambling, trying to figure out how to recover the systems usually taken care of by that particular System Admin.
The second was a result of 9/11. When I was working for that same DR Service Provider out of Scottsdale, AZ, I received a call the morning of 9/12, and the customer on the other end was in absolute hysterics. They were the West Coast office for a small company based in the World Trade Center (WTC). The IT department was in the WTC, along with the entire East Coast office. No one in their East Coast office survived. They lost everyone when the towers collapsed. They had absolutely no idea of what to do to start their recovery in order to get their business back up and running. Regardless of how important your information is to keep your business moving forward, people are your greatest asset.
You might be wondering, “If I’m not testing as if an actual disaster is happening, then how do I test?” With over 16 years of experience in the DR industry (and over 18 in IT), I have seen testing done in many different ways. The good news is that none of these ways is wrong! Some customers want to test one particular platform from their data center at a time. Some customers want to test subsets of their overall hardware configuration. This is a great approach, as practice always makes us better. Other customers may use test time to pre-test an upgrade or fix they are getting ready to implement at home. This gives them an opportunity to do a “live” run of the installation before they take it to production. Another example of testing does not involve the IT hardware at all. Sometimes it is a good idea to do a “paper” test. This is an exercise to walk through all recovery steps and documentation that would be required at time of disaster so that the customer can be confident that they have everything they would need to recover in the event of a disaster.
When is the best time to test?
That question is going to be different for everyone. Testing is recommended when any major changes take place that affect the IT organization or company, such as hardware and software upgrades or platform changes. Some companies are required to do audits every year, so they need to test prior to the audit. In a perfect world, the test would be a couple of months prior to the audit, so in the event there is an issue, the organization has time to correct it prior to the actual audit.
Where should you test?
In the past, there was no option but to go to the Recovery Center for DR testing. Advances in technology over the last 20 years have created numerous new possibilities. Today, with the network options available, customers can test from almost anywhere. One of the most common new models is for non-replication customers to send their tapes to the Recovery Center, where a recovery specialist loads the tapes and sets up a basic configuration on the hardware, and the customer tests completely remote from their own center. Many customers still like to be present at the Recovery Center during a test, as this is how they would operate during an actual disaster. Other customers use a hybrid of these two options—they send their IT DR team to the Recovery Center to handle the recovery while the end users remain home and test remotely.
As you can see, as technology has evolved, so have the means for DR testing. Whether taking advantage of the latest methodology and leveraging the latest technology or simply doing a paper walk-through and documentation check, testing is an important factor in being able to recover at time of disaster. The time invested in DR testing will only bring great returns when you are able to continue business in the event of an actual disaster.
If you are in IT, you have heard all about the CLOUD. What is the Cloud? What does it mean? Is it just the next marketing word for outsourcing?
I have been in IT for nearly 20 years, and nothing has taken over the market like the cloud has. Everywhere I turn, it’s “Cloud this and Cloud that,” whether it is production in the Cloud or DR in the Cloud. While production in the Cloud has undeniable value, I will focus on Disaster Recovery in the Cloud for the purposes of this blog.
When we talk about DR in the Cloud, there are two very different options. First, let’s clarify what the Cloud means—at least to me. Managing your IT in the Cloud simply means that you are allowing a service provider to allocate IT resources to you on an OPEX pricing model with your data, systems, and applications running on hardware that they own and store in their data center. Your responsibility typically starts above the hardware layer. You could call it “Infrastructure on Demand,” but the “Cloud” is way cooler when it comes to marketing.
DR in the Cloud starts with getting your backup data copied off site, but the key differentiator is what you do with that data in the Cloud at the time of recovery. Most of the major Cloud providers limit your DR services to storing your data off site. While this makes sense for data protection, it is severely lacking in recovery capability. Loading your data into the Cloud is simple and relatively easy to maintain—just send a little bit of change data every day. However, the recovery process is far more complex.
With TBs of data in production and off site in the Cloud, and only a WAN connection for access to this data, what will your full environment recovery look like? If you experience a disaster and have to rely on a WAN connection between your DR data repository and your DR recovery site, you will have some serious explaining to do. This recovery time will be days or months, neither of which is typically within an organization’s acceptable Recovery Time Objectives.
In order to minimize recovery time, you need a DR Cloud Provider that offers system hardware at the same location as your off-site backup data. This will lead to LAN speed recovery and a recovery time of merely hours or even minutes.
When you are considering DR in the Cloud, be sure you are looking for a DR Cloud Provider that offers off-site storage and systems for data recovery. These systems are critical to recovery; not having a reliable backup plan is analogous to driving your car without a spare tire. Ultimately, the best and only way to truly validate your DR in the Cloud solution is to perform a DR test.
Make sure you understand all of the details of your company’s intentions to move to the Cloud, and find a trusted advisor in the market to help craft the right solution for you. All too often, senior leadership gets caught up in the latest marketing buzz without truly understanding the technical details and implications. Get the right forecast for your business!