AWS Disaster Recovery: an overview and a backups tutorial
Have you ever lost data? It can make for a bad day.
Now, imagine you lose your customer's data. That can make for a bad week, if you're lucky. If you're not so lucky, it can cost money, customer trust, bad publicity, and much more.
In today's episode we are covering disaster recovery on AWS. In particular, we will be focusing on a few techniques to deal with data loss mitigation and resiliency.
When it comes to databases, at one time or another, most of us have dealt with configuration of automated backups, replication, and the headaches that can come from those tasks.
Today, we'll be taking a look at some of AWS's offerings for automatic backups, Multi-AZ, and read replicas.
Let's take a moment to describe some of the available backup options within AWS.
|Backup||This simply refers to the action of taking a snapshot of a database in its current state. This snapshot can then be used to recreate the database at that specific point in time.|
|Read Replicas||Outside of backups, this is the most commonly used configuration. In its most basic form, you have a master and a slave. The master propagates changes over to the slave.|
|Multi-AZ||Multi-AZ stands for multiple availability zone, which is very telling of its nature. A Multi-AZ setup consist of having multiple databases: a primary and one or more standbys that are in different availability zones.|
In Part 1, we'll focus on the simplest solution: backups.
By default, when you create an RDS instance in AWS, daily backups are enabled with a 7 day retention policy. The backups are performed during the daily maintenance window, which is defaulted to a random time based on the specified region.
In the RDS dashboard, let's click
Instances in the left navigation menu. Once we are on the
Instances page, let's click the
Launch DB instance button in the top right corner.
We should now be on a page similar to the one below, to select our database engine for our new instance.
PostgreSQL and choose
Now, we should be on the
Choose Use Case step. For our scenario, we can choose
Dev/Test and click
On this page, we can check
Only enable options eligible for RDS Free Usage Tier. This will limit our settings, but will be fine for our use case.
Scroll down and enter your
Password, then click next.
We are now on our last step:
Configure Advanced Settings.
On this page, we need to make sure that
Public Accessibility is set to
Yes, set our
Database Name, and scroll down to the
Here, we can see the default retention period is set to 7 days. If we set this to 0, it would disable backups. We have the option of scaling this out to a maximum of 35 days.
We'll leave the defaults here and move down to the
Maintenance section, you can see where you have the option of selecting a maintenance window, or leaving the default setting of
No Preference for a random window to be assigned.
For now, we can leave that to its default setting and click
Launch DB instance.
Once we've created the instance we can click the
View DB Instance Details button which will take us to the overview page of our instance. You may notice that
DB Instance Status is in a
Creating state. It will take a few minutes for the instance to be available.
Once the instance is available, we can click the
Instance Actions in the top right and see a dropdown of available actions. Specifically, we'll notice that we can trigger a manual snapshot with
Take Snapshot and restore with
Restore To Point and Time.
If we scroll further down the screen to the
Snapshots section, we can see that we have one snapshot. This initial snapshot is created as part of the creation of the instance and plays into how the
Restore From a Point in Time works.
Being able to restore from a point in time will use the latest snapshot before that point and use transaction logs up to the point so that you can restore from any point available in your retention policy.
So, let's dig into actually creating a snapshot and restoring.
Taking a snapshot
First, let's connect up to our database and add some data:
psql -Uroot -dtest -htest.cxywwt2zdqub.us-east-1.rds.amazonaws.com test=> CREATE TABLE todos ( id SERIAL PRIMARY KEY, name varchar(100) ); test=> INSERT INTO todos (name) VALUES test-> ('setup automatic backups'), test-> ('take snapshot'); test=> select * from todos; id | name ----+------------------------- 3 | setup automatic backups 4 | take snapshot (2 rows)
Now, let's take a snapshot.
We can scroll up to the top of the screen and click
Instance Actions and choose
Take Snapshot. It will ask us to enter a
Snapshot Name and then we can click
Once we've created the snapshot, it should redirect us back to the
Snapshots page and we should see our new snapshot.
As you can see, I've named mine
Now that we've created a snapshot, let's delete some data from our database.
test=> delete from todos; DELETE 2
Oops — we only wanted to delete one item, but accidentally deleted everything. Let's restore from our manual snapshot and see if we can get it back.
Let's go back to our
Snapshots page and choose our snapshot. Then, in the top right, we'll click
Snapshot Actions and choose
We should now be on the
Restore DB Instance page where we will configure a new instance to be created that our snapshot will be applied to.
On this page, let's select
db.t2.micro for the instance class, which is the same as the instance we took our snapshot from. I'm going to set the
DB Instance Name to
test-snapshot. Now, we can scroll to the bottom and click
Restore DB instance.
After a few minutes, our new instance should be available.
Before we can connect to the new RDS instance, we will need to go into the security group, click on the
Inbound tab and set up a rule to allow traffic from our IP.
Afterwards, we should be able to connect to the new DB instance and verify that our data is now available.
psql -Uroot -dtest -htest-snapshot.cxywwt2zdqub.us-east-1.rds.amazonaws.com test=> select * from todos; id | name ----+------------------------- 3 | setup automatic backups 4 | take snapshot (2 rows)
Now, we have access to all of our data from our snapshot; we could manually move bits of data over that we need, or point our application to our new database.
In this video, we went through an overview of backups, read replicas, and Multi-AZ. Then we configured a backup and created a snapshot. In part 2, we'll configure a read replica and a Multi-AZ.