DynamoDB Point-in-Time Recovery (PITR)

#aws

two key disaster recovery metrics

Term	Meaning	Simple Analogy	Example
RPO – Recovery Point Objective	The maximum amount of data loss (in time) your system can tolerate after a disaster.	How far back in time your backups should go.	If RPO = 10 minutes → if your system fails, you can lose at most the last 10 minutes of data.
RTO – Recovery Time Objective	The maximum amount of time your system can be down before it must be restored.	How fast you must recover.	If RTO = 1 hour → you must restore the system and resume operations within 1 hour of a failure.

If RPO = 5 minutes and RTO = 2 hours:

You have backups every 5 minutes → at most, you lose 5 minutes of data.
Your system must be restored within 2 hours → downtime cannot exceed 2 hours.
RPO = Data loss tolerance (time)
RTO = Downtime tolerance (time)

+------------------------------------------------------+
| 1. Enable PITR (Point-in-Time Recovery) on DynamoDB|
|    Table → continuous backups for last 35 days     |
+------------------------------------------------------+
                       |
                       v
+------------------------------------------------------+
| 2. Disaster occurs: accidental delete/corruption  |
|    Example: bug deletes orders at 3:00 PM         |
+------------------------------------------------------+
                       |
                       v
+------------------------------------------------------+
| 3. Determine Recovery Point Objective (RPO)        |
|    Example: RPO = 5 minutes                        |
|    → Means we can tolerate losing last 5 minutes  |
+------------------------------------------------------+
                       |
                       v
+------------------------------------------------------+
| 4. Restore table to desired point in time          |
|    Example: restore to 3:10 PM                     |
+------------------------------------------------------+
                       |
                       v
+------------------------------------------------------+
| 5. AWS creates a NEW table with data restored to   |
|    chosen point in time                            |
|    → Application needs to switch to new table     |
+------------------------------------------------------+

What is DynamoDB Point-in-Time Recovery (PITR)?

Think of PITR as a time machine for your DynamoDB table.
It allows you to restore your table to any second in the past 35 days.

RPO Recovery Explained

RPO = Recovery Point Objective → How far back in time you want to recover your data in case of a failure.

Example:

If your RPO is 10 minutes, that means: you’re willing to lose at most 10 minutes of data.
If your PITR is configured, you can choose a point in time within those last 35 days to restore the table — meeting your RPO requirement.

How it works

Enable PITR on the DynamoDB table.

This stores continuous backups of your table automatically.

When a failure occurs (like accidental deletion or data corruption):

Go to the AWS Console → DynamoDB → Your Table → Backups.
Choose Restore to point in time.
Pick the exact date and time (down to the second) you want to recover to.

AWS will create a new table restored to that point in time.

Example Scenario

You have a DynamoDB table for user orders.
At 3:00 PM, a bug in your application deletes some orders.
At 3:15 PM, you detect the issue.
Your RPO is 5 minutes — you need the database as it was at 3:10 PM.
With PITR enabled, you restore the table to 3:10 PM so you recover all orders except possibly the last 5 minutes of new data (which your RPO allows).

Key Points

PITR must be enabled before disaster — it doesn’t retroactively backup data.
Restoring creates a new table, you must re-point your application to it or migrate data accordingly.
PITR is best for protecting against accidental deletes, data corruption, or application bugs.