Disaster Recovery - On-Premise & Cloud
Download as PPTX, PDF3 likes2,296 views
This document discusses database backup and disaster recovery in the cloud. It defines key terms like disaster recovery (DR), which is preparing for and recovering from disasters, and defines a disaster as any event negatively impacting business continuity or finances. It notes statistics on businesses failing after data loss or disasters without recovery plans. Recovery Time Objective (RTO) is the time to restore systems after a disaster, while Recovery Point Objective (RPO) is acceptable data loss in time. The document discusses different disaster recovery strategies and their costs and impact on RTO and RPO, including local backups, online backups, pilot light, warm standby, and moving applications to the cloud for recovery.
![COSTS ON S3 (AWS)
0.085$ per GB durability 99,999999999%
$0.068 / GB durability 99,99%
$0.010 / GB durability 99.999999999% [glacier]](https://image.slidesharecdn.com/cloudconf2014-140404071044-phpapp02/85/Disaster-Recovery-On-Premise-Cloud-24-320.jpg)
Disaster Recovery - On-Premise & Cloud
- 1. CLOUDCONF 2014 Database: backup e disaster recovery in Cloud Walter Dal Mut @walterdalmut – www.corley.it – walterdalmut.com
- 2. DISASTER RECOVERY Disaster recovery (DR) is about preparing for and recovering from a disaster.
- 3. DISASTER Any event that has a negative impact on your business continuity or finances could be termed a disaster.
- 4. WHYWEARETALKINGABOUT DR? • Over 70% of businesses involved in a major fire either do not reopen, or subsequently fail within 3 years of fire. (Source continuitycentral.com) • 80% of businesses affected by a major incident either never re-open or close within 18 months (SourceAxa) • 70 percent of companies go out of business after a major data loss (Source continuitycentral.com) • 80% of businesses suffering a computer disaster, who have no disaster recovery plans, go out of business. (Source “A BridgeToo Far”, IBM BusinessRecovery Service & Cranfield, 1993) • A recent study from Gartner, Inc., found that 90 percent of companies that experience data loss go out of business within two years. • 80 percent of companies without well-conceived data protection and recovery strategies go out of business within 2 years of a major disaster. (Source: US NationalArchives and Records Administration)
- 5. RTO – RECOVERYTIME OBJECTIVE This is the duration of time and the service level to which a business process must be restored after a disaster
- 6. RTO what it implies? • Have a system that records 1000 transaction at hour • Take a snapshot of a system at 03:00 am (every day) • 10:00 am a disaster event occurs • You spend 1 hour to sort things out for the backup (off-site, preparation, etc.) • Recover operation takes 4 hours in order to get back to operate (at minimum service level) • 5 hours is the: RECOVERYTIME OBJECTIVE
- 7. RPO – RECOVERY POINT OBJECTIVE This describes the acceptable amount of data loss measured in time.
- 8. RPO –WHAT IT IMPLIES? • Have a system that records 1000 transaction at hour • Take a snaphot of a system at 03:00 am (every day) • 10:00 am a disaster event occurs • In this case we lost around 7000 transactions. • 1000 transactions 03:00 04:00 • 1000 transactions 04:00 05:00 • … • But: we are accepting 24 hours of data loss 24000 transactions (RPO)
- 9. DISASTER RECOVERY STRATEGIES Local tape backup Online backup Pilot-Light Warm Stand-by And More… $ $$$ $$$$$$ Seconds Days
- 10. ON-PREMISE & CLOUD Use cloud resources in order to provide business continuity
- 11. Disaster Recovery & Cloud? • On Demand • We can allocate and release new resources whenever we need • Cost Effective • Pay as you go model.We pay only for resources that we are effectively using • Scalable • We can scale freely and adapt our strategy thanks to autoscaling and other mechanisms • Secure • Control doesn’t mean security
- 12. FOCUS ON DATABASES We will focus on MySQL but you can apply to your infrastructure without any problem.
- 13. BACKUP & RESTORE Take a snapshot of a system and restore it when you need it
- 14. Application
- 15. Backup
- 16. Restore
- 17. RTO & RPO? Things to remember…
- 18. RTO What resources can impact on my RTO
- 19. RESOURCES ALLOCATION How fast we can set up all resources, eg: instances, network, etc etc.
- 20. DB RESTORE How many time the database restore can takes?
- 21. RPO What resources can impact on my RPO
- 22. DB SNAPSHOT How many time we need to recover all data from our snapshot?
- 23. Backup & Restore – RPO & RTO Configuration • Resources Allocation • ??? • Restore Operation • ??? • DNS • TTL 30 minutes • Snapshot • Every 24 hour Effects • RTO – RecoveryTime Objective • 30 minutes + ??? + ??? • RPO – Recovery Point Objective • 24 hour • Downtime per month • 99.8% availability 86.23 minutes • 99.95% availability 21.56 minutes
- 24. COSTS ON S3 (AWS) 0.085$ per GB durability 99,999999999% $0.068 / GB durability 99,99% $0.010 / GB durability 99.999999999% [glacier]
- 25. Pilot light We can let a little resource always active that can help us to activate a whole system
- 26. Replication Basically pilot-light is based on database replication strategies For MySQL async replication is used as base strategy http://www.slideshare.net/corleycloud/m ysql-scale-out-cloudparty-2013-milano- talent-garden
- 28. READ REPLICA ON A CLOUD PROVIDER
- 29. MOVETO CLOUD ON A DISASTER
- 30. RTO & RPO? Things to remember…
- 31. RTO What resources can impact on my RTO
- 32. RESOURCES ALLOCATION run and configure new instances typically takes a couple of minutes you have always to care about resources and times.
- 33. DNS PROPAGATION DNS takes a little while before propagate new addresses (TimeTo Live)
- 34. RPO What resources can impact on my RPO
- 35. DB REPLICATION Remember that Master/Slave replications are ASYNC! It implies LAG replication time and that impact with your RPO!
- 36. MONITORYOUR INFRASTRUCTURE Setting an RPO about 20 minutes implies that your replication LAG time should be always under 20 minutes!
- 37. Pilot Light – RPO & RTO Configuration • Resources Allocation • 20 minutes • DNS • TTL 30 minutes • Replication LAG • 20 minutes Effects • RTO – RecoveryTime Objective • 50 minutes • RPO – Recovery Point Objective • 20 minutes • Downtime per month • 99.8% availability 86.23 minutes • 99.95% availability 21.56 minutes
- 38. COSTS ON AWS 0.06$ per hour 1 m1.small~43$ per month 0.05$ per GB EBS 0.05$ per 1 million I/O requests EBS
- 39. WARM STANDBY Extends pilot-light resource allocation and preparation
- 40. Warm Standby
- 41. Warm Stand-by
- 42. Warm StandBy – RPO & RTO Configuration • Resources Allocation • 5 minutes • DNS • TTL 30 minutes • Replication LAG • 20 minutes Effects • RTO – RecoveryTime Objective • 35 minutes • RPO – Recovery Point Objective • 20 minutes • Downtime per month • 99.8% availability 86.23 minutes • 99.95% availability 21.56 minutes
- 43. COSTS ON AWS 0.06$ per hour 2 m1.small~86$ per month 0.05$ per GB EBS 0.05$ per 1 million I/O requests EBS ELB 20$ per month
- 44. PILOT LIGHT VS WARM STAND-BY Effectively in our examples Pilot Light is much more effective than warm stand-by. Doesn’t it?
- 45. DEPENDS ON ASSUMPTIONS We assume that we don’t need to scale out our database but that is enough to scale it up only! Resource allocation for new read replicas? How long does it takes?