Gone are the days when you had to build expensive data centers to implement data recovery plans. The public cloud has changed the way IT departments implement data recovery plans that translate into business continuity plans. You can not only use the cloud for storing data but also use it at times when you are struggling to recover from the disaster that has brought down the primary systems. When you are creating a plan for data recovery in the cloud, you must keep track of the infrastructure in hand, the data recovery requirements and the expected duration of the potential failover. To know more about how you must approach the cloud data recovery Philadelphia, take time to go through this article.
Identify the Applications that need Protection
Apps that deliver IT services form the backbone of the disaster/ data recovery plan. Begin by taking a close look at the applications that provide IT services so that you know what needs protection in the event of any disaster. Once you have identified the applications, create an inventory so that you have a list ready at hand that shows which application is linked to the delivery of which service/s. Although many organizations emphasize virtualization of servers, the need for physical servers remains.
Things to Document
The list that you prepare would comprise of three categories of servers – physical servers, virtual servers and a combination of both.
- Make a list of all physical and virtual servers deployed to deliver infrastructure DNS/DHCP servers and appliances and Active Directory (AD) servers.
- Physical servers are still relevant for delivering services, and there are reasons why organizations have to depend on it. Physical servers may be required for using custom hardware and custom operating systems and for scaling as well as performance requirements. Document all physical servers used for delivering services.
- There may be several virtual machines, often running into dozens or even hundreds that facilitate implementation of applications. Identify each need and include it in the list by looking at the virtual process requirements, memory, and storage.
The need for Listing
Listing the servers helps to identify infrastructure servers in advance so that you can prioritize which systems need top attention for bringing back fast when disaster strikes. To facilitate the Disaster Recovery process and to implement it quickly and easily you can configure in advance AD, DN and DHCP services to make it run in the cloud duly synchronized with their equivalents available onsite.
Understand Network Configuration
For successful working of disaster/data recovery in the cloud, it is critical to understand the network configuration. Spend time to know how the applications at the network layer are interdependent and co-related by taking into consideration any firewall and security configuration. Identify if there is latency dependence between servers or applications, understand the external bandwidth requirements and firewall rules that might be in place to manage traffic on site.
Determine requirements for Cloud Data Recovery
Data recovery does not mean that you have to recover the entire data at a time because, in the event of a disaster, not all applications require immediate. You must prioritize the recovery time for applications by setting specific criteria for each that determines how quickly you need to get it back into operation by using the following metrics.
- Recovery point objective (RPO) –
This is a measure of how much data loss is tolerable after the application runs post recovery. RPO of 24 hours means that it does not matter even if the data or system recovered is 24 hours out of date. Similarly, zero RPO means zero tolerance to data loss and all data that existed when the disaster happened must be back.
- Recovery time objective (RTO) –
RTO is a measure of how much time you can allow for data or system recovery by bearing the time of the outage. RTO zero means that it is not possible to allow any time lapse for disruption. If you can allow one hour for the system to be back on its feet, then it corresponds to RTO of 1 hour or 60 minutes within which the system restoration is necessary. The time is counted from the time the incident of outage occurred.
- Service level objective (SLO) –
SLO is a measure of overall application recovery and expressed in terms of percentage that is set for the organization. Since setting tight SLO entails more cost, keeping it flexible helps to optimize cost.
Do not forget to document all the factors listed above.
The last thing that you must document is how long you might use the cloud services for running data/disaster recovery. Since the total loss of onsite capabilities happen between far making a list of the types of incidents that you face would influence your decision.
Author bio:
Lucy Jones is a business consultant with expertise in cloud management. She has experience in dealing with data recovery related matters, and she always recommends the services of https://americantechpros.com/.
