RDS Automated Backup Retention – 8-Day Workflow Visualizer

01 Interactive Timeline

The 8-Day Snapshot Journey

Click each day to explore what happens to your data blocks. Day 8 is when the magic of reference counting kicks in.

02 Block Reference Counting

Surviving Day 8 – The Pointer Purge

When Day 1 expires, AWS doesn't blindly delete all its data. It uses reference counting to decide block-by-block what survives.

📦 Day 1 Block Reference Check

Every block in the expiring Day 1 snapshot is checked against the active snapshots (Days 2–7).

Day 1 Block B1

→ Referenced by Day 2,3,4,5,6,7?

⚠️ Block B1 was never overwritten — it's still referenced by Day 2 through Day 7's pointer index.

✅ AWS preserves B1. Day 2 absorbs the ownership of this block and becomes the new base snapshot.

🗑️ Obsolete Block Purge

Blocks unique to Day 1 that were overwritten on Day 2 are no longer referenced by anyone.

Day 1 Block B7

→ Referenced by Day 2–7?

❌ Block B7 was overwritten on Day 2. No active snapshot references it anymore.

🗑️ Block B7 is permanently purged from S3. You save storage costs for stale data.

💡 The Result: Data Consolidates Forward

After Day 8 runs the pointer purge, Day 2 becomes the effective new base snapshot, having absorbed all surviving blocks from Day 1. Your backup chain remains intact and every day in your 7-day retention window is still fully restorable — AWS simply reclaimed storage for blocks nobody needed anymore.

✅ No data loss ✅ Retention window preserved ✅ Cost optimized ✅ Transparent to user

03 Point-in-Time Recovery

Restore to Any Second

EBS snapshots give you daily granularity. Transaction logs give you second-level granularity. Together they power PITR.

1

🗂️ Daily EBS Snapshot

Every day during the configured backup window, RDS takes a full storage-level EBS snapshot. This is the base "disk image" for that day. Stored incrementally in S3.

2

📝 Continuous Transaction Logs

RDS continuously streams your DB engine's transaction logs (PostgreSQL WAL / MySQL Binlog) to S3 every 5 minutes. These record every single write operation.

3

📸 Find Nearest Snapshot

When you request a PITR restore, AWS locates the closest EBS snapshot taken before your target time. This restores the disk to that day's state.

4

⏩ Replay Transaction Logs

The DB engine replays all transaction logs from the snapshot time forward, up to the exact second you requested. Database reaches the precise state you need.

🕐 PITR Simulator — Pick a restore point

Move the slider to choose a point in time. See which snapshot is used as the base and how many hours of logs are replayed.

Day 1 00:00 Day 7 23:59

04 Key Takeaways

What Makes This Work

The seemingly magical restore behavior is pure engineering — no wizardry needed.

🧱

Block-Level Incremental Storage

EBS snapshots are stored as a complete map of block pointers. New snapshots only store changed blocks — unchanged blocks are referenced via pointers from previous snapshots.

🔢

Reference Counting on Expiry

On Day 8, AWS checks each block in the expiring Day 1 snapshot. Blocks still referenced by Days 2–7 are preserved. Orphaned blocks are purged. Day 2 becomes the new base.

🎯

Two-Phase PITR Restore

Phase 1: restore the nearest EBS snapshot (daily granularity). Phase 2: replay transaction logs (WAL/Binlog) to hit the exact second. Together they cover any point in the retention window.

💰

Cost-Optimized by Design

You're only charged for unique changed blocks stored in S3. The 7-day retention window covers compliance needs without paying for 30-day redundancy you may not need.

🔄

Transaction Log Continuity

Logs are shipped every 5 minutes. This means your RPO (Recovery Point Objective) is at most 5 minutes for PITR, while snapshots alone give you only daily granularity.

🛡️

Always Fully Restorable

Despite the incremental storage mechanism, every snapshot within the retention window represents a complete, restorable state of your entire database. There are no partial backups.