Disaster Recovery

Disaster recovery is a concept developed in the mid to late 1970s as computer center managers began to recognize the dependence of their organizations on their computer systems Disasters can be classified in two broad categories 1. Natural Disasters: These are floods, hurricanes, tornadoes, Tsunami & Earthquakes. 2. Man Made Disasters: These include hazardous material spills, infrastructure failure & bio-terrorism.
1

 Defining a disaster recovery involves two key metrics

1.

plan

2.

Recovery Point Objective(RPO) identifies how much data you are willing to lose in the event of disaster. This value is typically specified in a number of hours or days of data Recovery Time Objective(RTO) identifies how much downtime is acceptable in the event of a disaster.
2

Disasters in the Cloud

Backup and data retention: Fixed data such as your OS and common utilities belong in your AMI(American Megatrends India). Transient data file caches and other data that can be lost completely without impacting the integrity of the system. Runtime configuration data necessary to make the system operate properly in a specific context. Persistent data it changes constantly and a database engine is the best tool for managing it.
3

Database Recovery
The DB could be irreparably corrupted by whatever caused the instance to crash The volume could have gone down with the instance The instances availability zone could be unavailable You could find yourself unable to launch new instance in the volumes availability zones
4

Fig: RUBiS Tool Geographic Redundancy

 In fig., RUBiS is configured with 3 web servers and 1 Database at the primary site

This efficiently can be a major challenge: The primary site may have lost an arbitrary amount of data due to the disaster so the replication software must be able to determine what new and old state must be resynchronized to the original site

Organizational Redundancy The approach is to identify another cloud provider and establish a backup environment with that provider in the event you first provider fails Disaster Management Disaster has happened and have the tools and processes in place to execute your recovery plan One of the coolest thing is that all of this can be automated.
7

Disaster Management
Monitoring your cloud infrastructure is extremely important Monitoring system cannot live in either your primary or secondary cloud providers infrastructure There must be independent of your clouds Load Balancer Recovery is to greatly reduce the likelihood of load balancer failure Application Server Recovery if u are operating multiple appl. Servers in multiple availability zones your system as a whole will survive the failure of any one instance or even entire availability zone
8

Database Recovery
The DB could be irreparably corrupted by whatever caused the instance to crash The volume could have gone down with the instance The instances availability zone could be unavailable You could find yourself unable to launch new instance in the volumes availability zones
9

 Geographic Redundancy: Amazon provides built in geographic redundancy in the form of regions and availability zones
Internet

Load bala ncer

zone A

zone B

Appl.se rver

My SQL slave

My SQL master

10

 It consists of 1. Spanning availability zones 2. Operating across regions : It consists of a)DNS Management b)DB Management c)Regulatory issues

11

Benefits of the Cloud

The clouds pay-as-you go pricing model significantly lowers costs. Cloud resources can quickly be added with fine granularity. The cloud platform manages and maintains the DR servers and storage devices.

12

 VM startup can be easily automated, lowering recovery times after a disaster. Virtualization eliminates hardware dependencies, potentially lowering hardware requirements at the backup site.
Application agnostic state replication software can be run outside of the VM, treating it as a black box.
13

Advantages
1) 2) 3) 1) 2) 3) Cost Time Scalability Security Control Options
14

Disadvantages

15

16