Tuesday, May 7, 2019

Implementing a disaster recovery strategy with Amazon RDS


Implementing a disaster recovery strategy with Amazon RDS

Amazon RDS (Relational Database Service) is a managed service that makes it easier to set up, operate, and scale a relational database. Based on AWS high performance compute and storage, Amazon RDS supports the MySQL, SQL Server, PostgreSQL, MariaDB, and Oracle database engines. It offers a complete set of solutions for provisioning, patching, monitoring, and disaster recovery (DR). This blog presents three features in Amazon RDS that support DR: automated backups, manual backups, and Read Replicas.
Why do you need a DR plan?
For a production environment, it is important to take precautions so that you can recover if there’s an unexpected event. While Amazon RDS provides a highly available Multi-AZ configuration, it can’t protect from every possibility, such as a natural disaster, a malicious actor, or logical corruption of a database. To maintain business continuity, it is important to design and test a DR plan.
Understanding RTO and RPO
Recovery time objective (RTO) and recovery point objective (RPO) are two key metrics to consider when developing a DR plan. RTO represents how many hours it takes you to return to a working state after a disaster. RPO, which is also expressed in hours, represents how much data you could lose when a disaster happens. For example, an RPO of 1 hour means that you could lose up to 1 hour’s worth of data when a disaster occurs.
Different features of Amazon RDS support different RTOs and RPOs at different cost points:
Feature
RTO
RPO
Cost
Scope
Automated backups
Good
Better
Low
Single Region
Manual snapshots
Better
Good
Medium
Cross-Region
Read replicas
Best
Best
High
Cross-Region
As you can see, automated backups are limited to a single AWS Region while manual snapshots and Read Replicas are supported across multiple Regions.
Amazon Aurora
This post does not explicitly cover Amazon Aurora, because Amazon Aurora has slightly different DR features. However, many of the techniques presented are applicable to Aurora DB clusters. For more information, see the Amazon Aurora documentation.
Amazon RDS backups
Backups are a key component of a DR plan for your database. Amazon RDS supports two different types of backups: automated backups, and manual snapshots.
Amazon RDS backups follow these rules:
§  Your DB instance must be in the ACTIVE state for backups to occur.
§  Automated backups and automated snapshots do not occur while a copy is executing in the same Region for the same DB instance.
§  The first snapshot of a DB instance contains the data of the full DB instance.
§  The snapshots taken after the first snapshot are incremental snapshots. This means that only the latest changed data is captured and saved.
§  If it’s a Multi-AZ configuration, backups occur on the standby to reduce impact on the primary.
Note: Automated backups and manual snapshots are stored in an S3 bucket that is owned and managed by the Amazon RDS service. Hence, you are not able to see them from your Amazon S3 console.
For detailed information on backup mechanisms and backup storage, see Working with Backups in the Amazon RDS User Guide.
Automated backups
The automated backup feature of Amazon RDS is turned on by default. Amazon RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases. The first backup consists of a full instance backup. Subsequent backups are incremental in nature with snapshots containing only the blocks that changed since the previous backup. Each snapshot contains pointers to all of the snapshot data blocks that are required to reconstruct it. Deleting the earlier snapshot does not cause data loss as long as the data is still referenced by at least one snapshot.
Why do we need automated backups?
There are several benefits of having automated backups:
§  Data is stored in a S3 bucket that is owned and managed by Amazon RDS service.
§  You avoid the pressure of having to set aside time to do a manual backup and transfer it to a safe location.
§  You can choose a timeline that works for you: daily, weekly, or monthly.
§  Both manual and natural calamities are mitigated (for example, viruses, software malfunctions, or power outages).
§  Most importantly, you avoid the adverse effects of losing valuable data.
Automated backup window
The automated backup window is a weekly time period used for creating automated backups. The window is selected at random from an 8-hour block of time for each AWS Region. However, I strongly suggest that you set the backup window during low peak hours to prevent undue load on the server. For a list of the time blocks for each Region, see Backup Window in the Amazon RDS User Guide.
Automated backup retention period
The backup retention period is the time window during which you can perform a point-in-time restore (PITR). You can set a different backup retention period when you create a DB instance, and you can modify the retention period at any time.
For more detailed information, see Backup Retention Period.
There are a few differences between manual snapshots and automated backups:
§  Manual snapshot limits (100 snapshots per Region) do not apply to automated backups
§  The backup retention period does not apply for manual snapshots
§  Manual snapshots are not automatically deleted; they must be explicitly deleted.


No comments:

Post a Comment

Which Python course is best for beginners?

Level Up Your Python Prowess: Newbie Ninjas: Don't fret, little grasshoppers! Courses like "Learn Python 3" on Codecade...