A collection of articles about Disaster Recovery.





A message from the President and CEO of TeraGo
Message from Your CEO

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam sagittis euismod erat, eget varius libero vulputate a. Mauris a ligula urna. Suspendisse ullamcorper risus sit amet enim lacinia feugiat. Phasellus a lobortis felis.

Fusce ultricies magna a magna varius volutpat. Nam accumsan semper nisi, at venenatis nunc sollicitudin et. Sed hendrerit risus vitae tincidunt laoreet. Suspendisse ac enim ultrices, ultrices ante vestibulum, euismod arcu. Nullam consequat nisi metus, ac lacinia justo luctus vitae. Quisque a risus tellus.


Disaster recovery plans meet insurance policies

brian bloom brian bloom Published: 07/25/2015

Addressing the press around 10 years ago, former U.S. Secretary of State Donald Rumsfeld offered a terse explanation of how the U.S. security establishment evaluates risks. His somewhat inarticulate remarks about “known knowns” and “known unknowns” quickly became the subject of ridicule.

But beneath the tangled verbiage lies an important point that every IT organization should take to heart in their disaster recovery planning. Planning for disaster is an inexact science: there are many things you know you don’t know. Some argue that in the IT world, breaches, disasters, downtime — whatever you fear most —can and will occur, and that your planning should be built on that assumption.

Predictable chaos

Robert Beggs, CEO of Digital Defence, Inc., a Burlington, Ont.-based IT security firm, spoke about these necessary assumptions in an interview prior to his presentation at the recent World Conference on Disaster Management, held in Toronto at the end of June.
“Most people look at data security breaches as a unique, specific incident,” he says. “It is occurred, resolved with, and carry on. What I want to do is propose that they look at it as part of business management.  In the sense that instead of saying, ‘will it or will it not happen to us? How prepared are we?’ say right from step number one: ‘We’re going to suffer a security breach.’ Because there are too many actors, there are too many techniques for compromising data available.”
And when you know something bad is going to happen — for instance, everybody should expect to get into at least one car accident in their lives— but don’t know when it’s going to happen, there is something most normally do: buy insurance.
Insured: anything and everything
In the world of disaster recovery and business continuity, risk assessments and insuring against those risks should be of paramount importance in your strategy, says Wendy Hayko, President of ActionReady, a company based in Whitby, Ontario that helps clients prepare DR/BC plans, understand the impact of risks and how to mitigate them and, as she puts it, “making sure that when you’re dealing with those risks that you’re getting some kind of operational increase from it.”
Her company offers exercises to test DR plans for clients from the full range of industry sectors, from the private sector to government departments and NGOs. One key thing ActionReady tries to determine is how companies can save money by tying their DR to their most valuable insured resources. This is especially important for IT firms. Hardware, server recovery, data: “That kind of thing tends to cost a fair bit of money,” Hayko says.
“That’s where a lot of the costs end up showing up very quickly when you do have a business interruption event.”
For some companies, data itself is their most valuable asset, rather than physical servers, storage appliances or printers. So, is data a tangible entity that can be insured?
Absolutely, says Pete Karageorgos, manager of consumer and industry relations at the Insurance Bureau of Canada.
“You can basically insure anything,” says Karageorgos. “You can insure anything and everything — the cost is, ultimately, the cost or the price of the policy.”
Hayko says if your organization’s main line of business is gathering or analyzing data and you can quantity its value somehow, it can certainly be included in your business interruption insurance as an asset. It’s important here to determine, for example, “how much money you make from each unit of data, whether that’s megabytes or number of customers recorded,” she says.
“The other thing you can do with data is you can cover cost recovery of data as part of your extra expenses insurance, “Hayko adds. “Knowing what those costs are ahead of time will deduce the cost of that extra expenditure.”
While considered property (and thus not directly covered by business interruption insurance), there are certain ways (costing and income-generation measures) that will allow you to classify databases as insured assets, she says. They can also be covered under an extra expenses enhancement or “rider” on business interruption insurance.
“One of the things that I have worked with in companies is how a particular database is affecting your business income or your business profitability, and we’re able to get some statistics around, ‘without this database we have this much of an incurred loss’ or ‘with this database we have this much of an increased profit.’
“Either one of those two numbers will help with your business interruption and your extra expenses insurance.”
Getting out of the money hole — fast
According to David Senf, vice-president of the infrastructure solutions group at IDC Canada Inc., 70 per cent of mid-to-large sized enterprises have some form of DR/BC plan, while fewer than half of small businesses do. In Canada, the main concerns addressed in these plans are first, IT systems failure, second, security breaches, and third, power outages. And e-mail is the top application that Canadian companies want to bring back when something goes down, followed by financial and Web applications.
The losses from a downed e-mail server are quite difficult to quantify, as are those from certain other areas of business, wrote Rachel Dines, senior analyst for infrastructure and operations at Forrester Research Inc., in an email message.  But in general, “big cost savings on DR occur when you can prevent downtime,” she adds.
“The costs of downtime for many companies are huge, often running into the hundreds of thousands of dollars per hour. Downtime costs usually include productivity losses of employees, deferred or lost revenue, compliance or regulatory penalties, but can also include some of the harder to calculate things like reputation impact, customer retention [and] competitive advantage, to name a few.”
Since downtime is lost money, insurance companies can certainly be interested in how successfully a given company’s DR/BC plan could be applied, especially since commercial policies tend to be more specific than personal or homeowner’s insurance, says Karageorgos.
“There might be opportunities there for companies to work with brokers and carriers because, as an example, it would be of interest to an insurer to recognize a company that would have, perhaps, a business recovery plan in place that would minimize their downtime.
“The shorter timespan that a business is out of operation, out of its normal course of business, the less the impact will be on an insurance payout. So, it’s cheaper for the company, for the insurer,” he says.
“Companies that show that, ‘look, we’ve got plans in place that we may need this coverage [for] but we’ve done enough planning that odds are if anything does occur, we may be only be out of business or require additional costs to bring us back up to business [in] X number of days or X number of dollars.”
‘More than fluff’
Now that you’ve understood where insurance fits into the DR/BC  framework, let’s look at some quick tips on how to save money on your policy. First of all, you need to understand the unfortunate reality that despite your best efforts to produce one, not all insurance companies will give your IT disaster recovery plan the attention it deserves.

Part of the reason for this is simply that many of them aren’t equipped to review it. In general, the more complex your IT operations, the more insurance becomes a niche offering better suited to companies focused on a particular industry like your own.

Karageorgos offers an example of this: taxis.
“Not all insurance companies will insure taxis,” he says. “There are specific numbers that have expertise and so, typically, those are the companies, and maybe a handful, that will insure that type of business. Same thing for IT and data, and that sort of thing.
“On a smaller scale, if I have, let’s say, an accounting firm, and I want to insure my records, yeah, there’s the opportunity to do that. But if it’s a lot larger and more technical in nature, odds are that there are fewer companies that will have the expertise to underwrite that type of business.”
But when you do find the right insurer to review your plan, says Hayko, you can expect savings of up to 15 per cent, or at least, an expansion of your coverage. To hit the right notes, you’ll have to present a solid plan with real numbers (“make it more than fluff,” she says) and a standard methodology. You should also expect to present more than your DR/BC plan to an insurer, particularly for new coverage or a major revision.
In that case, the insurance company is bound to bring in accountants to dig deep into the dollar figures you’ve included in your planning.
“They’re looking at those plans for hard numbers, around how much loss are you expecting in what areas. And that’s where your BIAs (business impact analyses) are really, really going to be a strong player in this plan.”

How to prepare for disaster recovery

rachel dines rachel dines Published: 01/25/2014

If you woke up tomorrow and ran a marathon, how would you fare? It’s highly doubtful that you would successfully run the 26.2 miles without months of training, drills, and exercises.

The same is true for disaster recovery (DR): The chance that you could successfully recover IT operations without having exercised your DR plans on a regular basis is slim at best. The chance that you could successfully recover and meet your recovery objectives is zero. Yet Forrester finds that exercising DR plans is one area in which many organizations continue to fall short.

Although most enterprises claim they conduct a full exercise of their DR plans at least once per year, anecdotal evidence suggests that the majority of these exercises are not comprehensive and thorough; enterprises often just exercise a portion of the plan or a subset of applications. Indeed, many of the organizations Forrester has spoken with know that they need to improve their DR exercise program, but face barriers such as a lack of executive support, limited employee resources, and a fear of interrupting business processes. If this sounds all too familiar, consider the following 10 best practices for updating and improving your current DR exercise program:

1. Define Specific Exercise Objectives Upfront

Exercising for the sake of exercising is a waste of time. Make sure that there are clear and concrete objectives and goals set up front that will help determine the ultimate success of an exercise. One objective may be as simple as, “Verify our stated recovery time and recovery point objectives.” You could orient other objectives around training, such as, “Familiarize the database administrators with the plans for recovering Oracle.”

2. Include Business Stakeholders

Business owners play a vital role in your DR exercises, and you need to involve them from the start of the exercise until you have recovered all services. Business stakeholders should verify the successful recovery of services. This has the dual benefit of ensuring that you have properly recovered business processes with all of their critical components as well as ensuring that business stakeholders know what to expect in terms of recovery capabilities and performance at the recovery site during an actual declaration.

3. Rotate Staff Responsibilities

It’s important that the person who wrote the DR plan is not the same person who executes the test, as it is unlikely that that individual would be available in a real disaster. Some companies Forrester interviewed went so far as to have employees with little specific knowledge of a system executing those tests, such as a system administrator running the database DR test. An important secondary benefit of a DR exercise is training; by assigning staff to take on new roles during exercises, you are essentially cross-training staff in different areas.

4. Develop Specific Risk Scenarios For Your Exercises

Many enterprises conduct their DR exercises without specific scenarios; they tell the response team to assume the data center is “a smoking hole.” It is important, however, to define specific risk scenarios even for DR testing for two main reasons: 1) It provides a more realistic situation for the response team to react to, and 2) different scenarios require different actions from the IT staff. For example, the DR plan for a short outage at the primary data center that only requires resuming operations would be different from a long-term outage that requires failover (and eventually failback), which in turn would be different from scenarios where only portions of the IT infrastructure were down.

5. Run Joint Exercises With Business Continuity (BC) Teams

In our research, Forrester found that many BC and DR teams run all of their exercises separately and often fail even to communicate when they run exercises. However, you should aim to exercise the full enterprise BC and DR concurrently at least once per year. This is especially important if the data center is in the same location as corporate headquarters.

6. Vary Exercise Types From Technical Tests to Walk-Throughs

A common misconception in IT is that walk-throughs and tabletop exercises are not necessary for DR exercises. While it’s true that these types of exercises won’t test the technical capabilities of a failover, they are still critical for training, awareness, and preparedness. Interviewees told us that the majority of the time, exercises that didn’t go as planned actually struggled most with communication and employees’ understanding of their roles during the exercise. Non-technical exercises such as walk-throughs and tabletops will help make these processes go more smoothly.

7. Make Sure to Test All IT Infrastructure Concurrently at Least Once Per Year

Waiting longer than a year risks too much change in IT environments and personnel — you need to bring new staff members throughout the organization up to speed on DR plans. The most advanced firms run full DR tests as often as four times per year. In between full tests, most firms conduct component tests that vary in frequency depending on the criticality of the systems and rate of change in the environment.

8. Identify Members for the Core DR Response Team

The stress of working under time and resource restraints for long hours, often during nights and weekends, is something people cope with in different manners. When picking a core response team to lead IT recovery, it’s important to pick people who can work under extreme amounts of pressure (and sleep deprivation). During an exercise or test, identify those individuals who can remain calm and collected.

9. Learn From Your Mistakes

The point of running DR exercises is to find potential barriers to recovery while in a controlled environment. If you aren’t encountering problems during your exercises and tests, it’s more than likely you aren’t looking hard enough, aren’t testing thoroughly enough, or you have designed scenarios for recovery that are too simple. When you complete exercises and tests and you have identified problem areas, use what you have learned to update plans and create best practice documents.

10. Report Results to Stakeholders

If your organization has recently made significant investments in improving preparedness, most likely executives and other business stakeholders want to know what the return is on their investment — how prepared are you? Reporting exercise and test results regularly and in a timely fashion gives executives and business leaders visibility into your DR program. Remember that the results are not pass/fail but should detail aspects of recovery that went well and areas for improvement.

Cloud disaster recovery: what you need to know

brian bloom brian bloom Published: 03/07/2012

Moving your disaster recovery infrastructure to the cloud can help your business save. But picture those savings in dollars, not hours and minutes.

One advantage of cloud computing is its scalability — use only what you need, when you need it. And of course, another is having quick access to remotely stored data.

Since most enterprises don’t face catastrophic data disasters very often, doesn’t that make cloud the perfect choice for DR?  You won’t pay until disaster strikes (which hopefully will be never) and if it does, you’ll be back up and running in no time.
Well, sort of.
“The cost savings are pretty significant when you look at it this way,” explains Forrester Research analyst Rachel Dines. “In a disaster recovery in the cloud model, most of the time you’re only paying for storage and you only pay for the compute resources when you’re testing or having a disaster.
“In a traditional model, in some way or another, you are paying all the time for the compute resources. From the most straightforward approach, if you own two data centres yourself, if you have to buy servers to go at the other data centre, that’s an investment.”
However, Kaushik Ray, director of cloud solutions at Savvis Inc., says it’s a “misconception” that cloud DR is a simple pay-per-use model that will bring your whole system back up in a heartbeat. “That is true for your application or compute,” he says, “but there’s nothing out there that will automatically recover data or storage instantaneously or in a short period of time.  And therefore, it means that you always need to have your data on your disaster recovery site.”
 “You have to pay for that storage,” he says. “You have to pay for that replication that’s going on, even if you’re not using that data.”
“Those costs don’t go away with cloud. What does go away is if you had a large amount of cost on the compute side or the application layer. Then yes, that does go away.”
The costs don’t completely go away or “zero-ize,” Ray adds, but will be reduced significantly, depending on your RTO. If your recovery time objective is less than four hours, when disaster strikes “you need to have those application images parked on the disaster recovery site so that you can basically just spin it up.”
Part of the confusion over cost structure may be due to the fact that cloud disaster recovery is very much a new product.
There are a number of options now available, but most of have only come to market in the past year, says Dines, and “it’s not something that a lot of enterprises are going to want to jump into yet with both feet.”
For large enterprises that already outsource their DR, moving it to the cloud probably wouldn’t be “extremely painful,” she says. Those who have handled their disaster recovery in-house might be in for a bit more discomfort.
Dines says she uses three categories to define the market for cloud DR.“There’s do-it-yourself, there’s disaster recovery-as-a-service and there’s cloud-to-cloud disaster recovery.”
The first involves simply using cloud as a vessel for your own DR infrastructure, the second is offered more as a pre-packaged service, and the third is a way to set up fail-over across multiple cloud data centres, an option that would appeal to firms with very low tolerance for downtime or data loss, such as financial institutions.
“I’m seeing the larger enterprises being most interested in the do-it-yourself disaster recovery,” says Dines, “mainly because they feel that they have the expertise on-staff and some of the capabilities already in-house to do a lot of the orchestration and the fail-over and failback.”
In a broader sense, John Weigelt, national technology officer at Microsoft Canada Inc., says he sees cloud DR as an “area of great transformation.”
“In the past,” he says, “when you look at disaster recovery we have this vision of our main site, our primary site, perhaps a cold standby/hot standby that’s someplace geographically close so we can drive to it, but not so far away that it takes us on a plane to get us there.
“The cloud, with its fabric of computing, really changes that model because we don’t really have a hot standby/cold standby. We really have a collaborative environment that is geographically distributed.”
But Jeremy Suratt, senior solution marketing manager in Iron Mountain Inc.’s data backup and recovery section, argues that DR strategies that rely on network connectivity, whether traditional data centres or clouds, have an Achilles heel:  the communal well can be poisoned.
“What happens if your hot/cold sites are corrupted by the same virus or issue that affected your primary data centre?  In that case, tape is more reliable because it’s stored offline and out of reach, protecting your data from corruption.”
However it is accomplished, disaster recovery is starting to define how businesses operate. Enterprises are starting to realize that upgrading their DR infrastructure can be a way to get the jump on their competition, says Dines.
“I think more and more, companies are seeing disaster recovery as strategic differentiator, so thinking about it in terms of ‘if I have downtime, my competitors have an opportunity to seize market share from me, and vice-versa.’”
“It does actually, in certain industries, become incredibly competitive, especially looking at things like anything e-business, any kind of online retail or e-business.”

Brian Bloom is a staff writer at ComputerWorld Canada. You can find him on Google+. He covers enterprise hardware and software, information architecture and security topics.


Six steps to keep disaster recovery real

Mark Els Mark Els Published: 09/14/2016

Unless we’re living under skies of brimstone and hellfire, most companies shouldn’t have to replicate every piece of data to protect their business from the next cataclysmic event. Nor should they necessarily have to cough up millions for a mirror site that traces every network transaction.

And let’s face it, unless you’re cyber-cynical, catastrophes are extremely rare. Be that as it may, enterprises are increasingly being held accountable for their data and prudence points to being prepared.

We went on the hunt for the most commonly overlooked elements are in today’s disaster recovery plans.

Understand business needs

Ultimately IT is there to serve business, and disaster recovery planning should be no different.
Sound hackneyed? Well, most IT shops still don’t get it. Experts in the field insist people are still making technology decisions, and not business decisions.

A lead consultant in business resiliency says recovery capabilities have to be matched to the business requirements.

“Understand that disaster recovery and business continuity are part of overall risk management,” he says. “It’s not just an IT thing.”

IT has a responsibility to understand how business workflow ties into business applications, and how those applications, in turn, are supported by infrastructure.

“One of the challenges I see all the time is that business continuity and disaster recovery fall back to the responsibility of IT, and IT’s normal response is to throw technology at it,” says another data recovery expert.

“We tend not to spend enough time communicating out there with the business units and understanding what their business problems are,” he says.

Know your enemies

As a type of insurance policy, it’s helpful to know what threats and vulnerabilities you’re likely to come up against.

Unless you’re in a tornado area, on a fault line or flood plane, you probably won’t be building a mirror site of your entire IT infrastructure.

But going through that vulnerability and risk assessment can be a heated debate, says George Kerns, president and CEO of Fusepoint Managed Services Inc.

The budget for a recovery plan is large compared to the operating budget, and if the chance of a disaster occurring isn’t high, how do you avoid spending too much?

“I think this has to come down to a rational conversation between the CIO and the CEO,” says Kerns. “They have to be aligned on what risks they’re willing to take with their business.”

Catastrophic failures of data centres are rare. They’re typically built for high availability, located in a secure area and supported by a network operations centre.

“Your disaster recovery plan is going to depend on how data- intensive your business is and what your company’s appetite for risk is.”

Map your support system

Often it’s not clear how an application is serviced up to a business process, and how the underlying infrastructure supports those applications. Unless you know all those pieces, you’re not going to be able to determine what a sensible disaster recovery plan looks like, say out experts.

Without system-to- application mapping, you cannot understand the interoperability and interrelationships you need to manage.

“This helps you understand the recovery bundles and where those single points of failure are in the environment.”

Having that business workflow to application to system mapping can also drive the discussion around cost. It gives executives a clear sense of the extent to which IT supports business.

Kerns says a disaster recovery plan can be dissected in different ways. Depending on how fast you need to get a piece of your system back up and running, companies can look at recovery sites that are cold, warm or hot. Not every business application is as critical as the next.

Get the message out

Consistent communication is another key element that’s often overlooked. Business needs IT’s participation and IT needs plenty of time and access to resources.

“You have to have that executive-level buy-in or you’re probably going to put up a facade of a plan without investing in the resources,” says Kerns. “And the people who come up with the plan have to engage the people who are running IT operations,” he adds.

On another level, no one ever wants to talk about the gap in perceptions and expectations of recovery time.

Our experts suggest most business units believe their IT systems can be back up within hours, while IT will estimate a couple of days and an actual assessment of the technology will reveal a further gap.
It’s not only about communicating business requirements to the IT people, sometimes it’s just being able to get in touch with people when something goes wrong.

Fail your test

Like any type of planning exercise, you have to test it and test it and test it.

Our experts suggest there is very little in the way of full end-to-end testing for applications across multiple platforms.

“This is a big area where more testing needs to be done, with a more rigorous, more integrated approach and a stronger level of governance around it,” says one of our leaders.

And don’t test to pass; you have to test to fail, they say. “If it fails, only then can you understand what to fix.”

Many organizations think they’re in a better position than they really are. “One of the biggest drawbacks is this pass-fail mentality. It doesn’t help to set yourself up to pass.”

You have to make sure it all fits together and there are no holes in it, adds Kerns.

“A lot of people put some effort into developing a plan so they can check the box and say they have a plan,” he says. “But forced into a true recovery situation, most companies would find their plans haven’t been updated and they’ve never been through a full-blown test.”

Keep up with change

Disaster recovery planning is not a one-time event. As your IT system evolves with new applications, upgrades and configuration changes, these changes will likely affect your recovery plan.

“Keep your technical recovery capabilities consistent with the latest production configurations.”

As new technologies and applications are added, they frequently don’t get copied over and the recovery side of things quickly falls out of date, he says. Change management processes and the application development lifecycle need to take recovery into account.

It’s an evergreen plan that must be kept current. “You can’t be working from something that’s three months or six months stale,” says Kerns.

“You have to keep rolling these things through so that you’re prepared.”


Eight best practices for IT disaster recovery

CSO staff CSO staff Published: 09/15/2015

Given the high number of blackouts, hurricanes and other disasters that have come our way during the past few years, many CIOs are wisely reexamining their disaster recovery strategies. CIO Executive Council members share some of their tried-and-true methods with CSO readers.

1. Empower your staff. Dedicate a department within IT to manage business continuity planning and disaster recovery.

2. Divide and conquer. To ensure business involvement, some CIOs separate business continuity planning and disaster recovery into two initiatives, each with its own governance and goals.

3. Make sure the plan can stand alone. Develop a plan that will work with or without the people who created it.

4. Challenge the business. Request that individuals think about how long they really go without a particular application.

5. Align disaster recovery with application development.

6. Test your crisis management team with mock disasters. Tabletop tests won’t cut it.

7. Try before you buy. Test products and new technologies, before you purchase.

8. Hold postmortems and adjust. What you do with the results of the test is a critical part of disaster recovery planning.


How long do you have to recover after a disaster?

Bruce Stewart Bruce Stewart Published: 12/11/2013
Server Recovery

The typical Canadian enterprise is certain it has recovery of the business in the event of a disaster well in hand.

Few of them have ever worked out exactly how much time to recover they have. So far, it’s only the lack of a major disaster that’s hidden that.

Disasters come in a variety of forms. Anything that corrupts data, for instance, qualifies, even though we don’t think of it as a “disaster”.

In today’s packaged software world, and with an increasing percentage of corporate assets parked in cloud-based applications, the potential points of corruption or failure are increasing. That’s not a reason to eschew the offerings — but it does suggest that it’s time for enterprises to up their game on recovery.

Let’s take an example. About a decade ago, one of Canada’s chartered banks put in an application change that started corrupting its data.

The error was caught fairly quickly — within one business day — and the requisite backups existed. So, too, did the journalled transactions allowing all the work done before the error was caught and the systems shut down to be recovered.

Few amongst us journal all inbound transactions since the last backup. We’d rather save pennies on disk space.

The problem for the bank — and it’s a problem for most enterprises — is that business doesn’t stop just because you have a problem. So new transactions were being added to the journals even as recovery from the backup and processing of the journal was done.

In fact, it took a little over a month to get the bank back to running in real time. Hours of corruption — day after day of catch-up.

It wouldn’t have taken too many more hours having not caught the problem, in fact, to get to the point where the institution would never have caught up: forever into the future, it would be journalling, then processing later, because it was behind.

Now, add the requirements for compliance to Bill 198, or Sarbanes-Oxley to the mix. How does an executive sign their life away saying they know the operational status of their enterprise when the quarter can’t be balanced on time? How does their compliance auditor sign off?

Or think about publicly-traded organizations: financial statements must be filed, or trading is halted. (This, in turn, sets off a flurry of credit-related issues: suppliers stop extending credit, and don’t ship goods.) If you can’t close the books because you haven’t “completed” the period yet, you can’t file.

In the case of the banks, adequate reserves are dictated by the Bank of Canada, and must be maintained. Likewise, instruments (e.g. cheques) drawn on your bank but presented for payment at another bank must be exchanged and the net positions made whole, transferring funds to do so. It would be easy to deplete a bank’s capital simply from being unable to provide matching data, forcing their reserves to be raised unnecessarily.

Every business — not just a bank — has these issues. We all run on a thread of continuity. Break it, and pieces start falling down all over the place.

Business continuity, for far too long, has been seen as a “disaster recovery problem for the data centre”. Or as a “where do we send the troops if the office can’t be used” problem.

Only a very few companies have done the analyses required to figure out just what their recovery window is, how to deal with missing or corrupted data, and how to restore confidence so that that thread of continuity can be kept.

If your enterprise still sees this as an “IT problem”, then you don’t have effective IT governance. For it’s really a business problem, and needs to be handled that way.

The day we decided to use IT to automate was the day this problem became real. Stop talking about “mission-critical” applications. Start talking about how the business keeps its thread of confidence in continuity.


Learn more about Disaster Recovery and Cloud Migration

Your COMPANY  believes that migrating to the cloud is not a single step or event, but a journey that involves planning and managing the migration over time. We support our customers at every step of their cloud journey. For guidance on best practices and technology for your digital strategy, check out our website www.yourcompany.ca or call us at 1-888-899-3333

Table of Contents