RDS PostgreSQL: Backups, Restore and Failover — Challenge
Take a snapshot, destroy data on purpose, and restore it — then measure how long that actually took.
- Time
- 27 min
- Level
- Intermediate
- Objectives
- 4 objectives
- Cost
- Low cost
Before you start
You will need
- AWS CLI v2, configured
- psql
You will be able to
- Restore a database to a point in time, not just to a snapshot
- Measure a real RTO instead of assuming one
- Explain why a restore creates a new instance
Cost — Low cost
A `db.t3.micro` is free for 12 months on a new account and ~$13/month after. Snapshots are billed beyond the free allowance. Delete the instance the same day.
You are done when
0 of 4
The goal#
Achieve the same outcome as RDS PostgreSQL: Backups, Restore and Failover, from an empty starting point, without the steps.
There is a backup. Nobody has ever restored it.
A backup that has not been restored is a hope, not a backup — and the only way to know your recovery time is to measure it with a stopwatch.
What must be true when you are done#
- A manual snapshot exists and you can list it.
- Data deleted on purpose is recovered, verified by querying it.
- You can state the measured RTO — wall-clock minutes from decision to service restored.
- You can explain why the restored instance has a different endpoint.
Rules#
- Do not open the guided lab until you are finished, or until the same problem has held you up for 20 minutes.
- Documentation is allowed and encouraged.
- Verify every criterion with a command whose output you can read.
If you get stuck#
- What did you expect, exactly?
- What happened instead — the error text, not a paraphrase?
- Which layer is that error from?
- What is the smallest command that proves the layer below is fine?
The concept behind it
Phase complete · 03 AWS by hand
You can now: You can build a network, grant least privilege, serve a site through a CDN, and restore a database — without any automation.
Next phase
Lab 19 of 58 on the project path