Disaster Recovery is one thing you hope you never need, but if you do, you’ll be very happy if you have right plan in place. Whether you are outsourcing your Disaster Recovery solution or keeping it in house, the steps required to implement it are somewhat complex, but very important. In this 3 part series, we’ve drafted an outline of how to build a remote DR site for your IT.
photo credit: comicbookmovie.com
We’ll address each step in more detail:
- Determine the business requirements for RTO and RPO
- Determining the right location
- Determining if the right systems are available at the location
- Virtualization of the primary and backup environments/production systems
- Moving the data
- Keeping the data synced
- Building the failover environment
- Testing and proving the disaster recovery program works
1. Determine the business requirements:
Your “business requirements” boil down to one thing: figuring out how long you can afford to be without your IT. Is it seconds? American Airlines has a zero second threshold. They lose thousands maybe millions of dollars for each second their system is unavailable. Your business operations may not be so mission critical and are able to skip a heartbeat for minutes, hours, days — without a significant impact on your bottom line.
Ask your executive staff, what can the company financially tolerate in terms of downtime? And just as importantly, what can you withstand in terms of rollback of data in a failure situation? How fresh does your data rollback need to be?
These two measurements are your RTO or Restore Time Objective and RPO or Restore Point Objective.
RTO / Restore Time Objective is: how quickly do we need to be back in business?
RPO / Restore Point Objective is: data should be restored as it was on the last day, hour, minute, or last second even (think about a bank – they can’t afford to miss a single transaction). Then ask yourself, what’s the technology required to achieve those objectives? Your RTO and RPO are going to dictate the options available to you for your disaster recovery program.
2. Determining the right location:
Where do you want to “put” your Disaster Recovery environment? Contrary to common belief, “the cloud” is not up in the air somewhere, it’s in a city near you. If you want your data in “the cloud,” you need to understand where the data center, a.k.a. the cloud is that you’re floating around in.
Why is the cloud location so critical? Consider events from earlier this month. The Derecho Storm that hit the Washington DC area left the region without power for an extended period of time, and with it took down popular internet sites Netflix, Pinterest and Instagram temporarily. Consumers were off line for an entire week and even big companies were forced off line. Behemoth Amazon’s cloud services were interrupted – because their “cloud” was located in the disaster zone
While no location is completely without risk, the ah-ha moment here is that if you’re going to choose aDisaster Recovery provider, you need to know where their facility is located so you mitigate your risk. You don’t want your cloud provider to be stricken by the same disaster as your primary facility.
Now that we’ve given you something to think about concerning the cloud, your RTO and RPO, we’ll continue our discussion on building a remote Disaster Recovery site in our next article with: determining the right systems, virtualizing the primary and backup data, and finally moving the data. Part three will address synchronization, the failover environment and testing.
Walang komento:
Mag-post ng isang Komento