Ravindra BagaleCourses & study guides मराठी Track your progress

DynamoDB Backup, PITR, Export, Import and Restore

By , trainer LinkedIn Last updated:

Backups are useless until you restore. Casablanca SRE Fatima Zahra and Berlin bank lead Lucas Meyer said: PITR was on, nobody had restored in 18 months — first drill failed IAM. On-demand backup for named snapshots; PITR for continuous window; export for analytics copies. Cost awareness: capacity and cost.

What you'll learn in this chapter

  • Explain PITR vs on-demand backup
  • Run backup and restore mental RPO/RTO
  • Use CLI for backups and continuous status
  • Map across industries
  • Lab + cleanup

1. Everyday example: phone photos

On-demand backup = freeze one album now. PITR = rewind timeline within days. Export = copy album to a USB (S3). Meera restores a wrong delete with PITR; weekly on-demand before schema changes.

2. Vertical steps

Why -> What -> How -> Lab -> CleanupWhyWhatHowLabCleanup
Always cleanup

3. Why do we need this?

Why do we need this?

Fat-finger deletes, bad deploys, and ransomware need table-level recovery. App-level undo is not enough for whole-table mistakes.

4. What is it?

What is it?

On-demand backup: full snapshot you name. PITR: continuous backups, restore to a second within the window (commonly up to 35 days). Export: dump to S3 (not a hot failover). Restore creates a new table — cutover is your job.

5. How to do it (step by step)

How to do it (step by step)

  1. Write RPO/RTO for the table.
  2. Enable PITR on irreplaceable tables.
  3. Take on-demand backup before risky changes.
  4. Practice restore to a new lab table; verify item counts.
  5. Export to S3 when analytics need a copy.
  6. Document IAM who can restore; run quarterly drill.

6. Commands with output and meaning

aws dynamodb update-continuous-backups --table-name lab-ddh-bak \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
aws dynamodb describe-continuous-backups --table-name lab-ddh-bak
# Output: PointInTimeRecoveryStatus ENABLED
aws dynamodb create-backup --table-name lab-ddh-bak --backup-name lab-ddh-$(date +%Y%m%d%H%M)
# Output: BackupStatus CREATING then AVAILABLE
aws dynamodb list-backups --table-name lab-ddh-bak

Enable PITR; describe confirms. create-backup names a snapshot. Restore APIs create a new table — plan cutover.

7. Industry stories

  • Bank (Lucas): PITR on ledger; quarterly restore drill.
  • SaaS (Omar): on-demand before migration weekends.
  • Retail (Aisha): export nightly for BI; PITR for ops.
  • Healthcare (Rohan): backup vault policies + IAM break-glass.
  • Gaming (Carlos): PITR off on disposable leaderboard labs.
  • Travel (Omar): restore runbook includes GSI recreate checks.

8. Lab

How to do it (step by step)

  1. Create lab-ddh-bak; put 3 items; enable PITR; create-backup.
  2. describe-continuous-backups; list-backups.
  3. Delete backups you created if charged; delete table.

Cleanup (stop billing)

  1. Delete lab resources you created.
  2. Confirm with describe that names are gone.

9. Ops checklist before you ship

  1. Confirm TTL attribute name and units (epoch seconds).
  2. Decide soft-delete vs hard-delete vs archive-to-S3.
  3. Enable PITR on any table you cannot rebuild from source.
  4. Document RPO/RTO and who runs restore drills.
  5. If multi-region: pick write stickiness and conflict rules.
  6. If DAX: prove cache-miss path and warm-up plan.
  7. Tag Owner + Expiry on every lab resource.
  8. Budget alert in the account before load tests.

10. Copy-paste DynamoDB CLI starters (batch 2)

export AWS_DEFAULT_REGION=ap-south-1

# TTL status
aws dynamodb describe-time-to-live --table-name ShopApp

# PITR / continuous backups
aws dynamodb describe-continuous-backups --table-name ShopApp

# On-demand backup
aws dynamodb create-backup --table-name ShopApp --backup-name lab-shop-$(date +%Y%m%d)

# List backups
aws dynamodb list-backups --table-name ShopApp

# Global table description (v2)
aws dynamodb describe-table --table-name ShopApp --query 'Table.Replicas'

11. More industry stories

  • Retail (Aisha Khan, Dubai): TTL clears abandoned carts; soft-delete keeps 30-day undo.
  • Bank (Lucas Meyer, Berlin): PITR on ledger table; restore drill every quarter.
  • Travel (Omar Haddad, Amman): Global Tables for catalog reads; inventory writes sticky.
  • Gaming (Carlos Rivera, Mexico City): DAX for hot profile Gets; never cache money ledgers.
  • Social (Priya Nair, Kochi): adjacency edges for follows; sparse GSI for unread inbox.
  • IoT (Mei Lin, Shenzhen): device#day PK + TTL 14 days; rollups to S3.

12. Glossary (batch 2)

TermMeaning
TTLTime to Live — attribute with epoch seconds; DynamoDB deletes later
Soft deleteFlag deleted=true; item remains until TTL/archive
PITRPoint-in-time recovery — continuous backups window
Global TableMulti-region replicated DynamoDB table
LWWLast-writer-wins conflict resolution on replicas
DAXDynamoDB Accelerator — in-memory cache cluster
Adjacency listEdge items modeling relationships in one table
Fan-outWrite once; push copies to many feeds/inboxes

13. Practice: explain out loud

  1. 60s: TTL vs soft-delete vs S3 archive.
  2. 60s: PITR vs on-demand backup.
  3. 60s: when Global Tables help and hurt.
  4. 60s: DAX consistency trade-off.
  5. 60s: CartLite checkout keys in one breath.
  6. 60s: follow edge vs feed item.
  7. Record once; cut filler; record again.

14. Safe lab hygiene

  • Use ap-south-1 labs with a budget alert.
  • Prefix lab tables with lab- and your initials.
  • Delete replicas, DAX clusters, and backups you created for labs.
  • Never enable Global Tables on production without a write plan.
  • Tag every resource Owner + Expiry.
  • Export/import labs can create large S3 bills — delete prefixes.

16. Delete / archive decision pad

NeedPreferWhy
Undo 7-30 daysSoft-delete flagUser restore
Hard expiry, no readTTL attributeAuto delete later
Compliance keep coldExport/archive to S3Cheap long store
Mistake recoveryPITR / backupTable-level restore

17. Ten oral drill questions

  1. What units does DynamoDB TTL use?
  2. Does TTL delete instantly?
  3. PITR window typical length?
  4. Global Tables conflict default?
  5. When sticky writes matter?
  6. DAX vs API Gateway cache?
  7. Cart PK for a shopper?
  8. Order lines under which PK?
  9. Follow edge SK example?
  10. Unread inbox sparse GSI idea?

18. RPO / RTO mini workshop

  1. Write the worst data loss you can accept (RPO) in minutes.
  2. Write how long restore may take (RTO) before business pain.
  3. Map: on-demand backup vs PITR vs multi-region replica.
  4. Schedule a restore drill on a lab table this month.
  5. Name the person who runs the drill.

19. Cost watch list (batch 2)

  • PITR storage and on-demand backup storage.
  • Global Tables: replicated WCUs in every region.
  • DAX node hours even at idle.
  • Export to S3 + S3 storage + Athena later.
  • Streams + Lambda still bill during TTL deletes.

20. Project Definition of Done

  1. Access patterns written and peer-reviewed.
  2. Sample items drawn for happy path + one failure.
  3. Lab table created, exercised, deleted (or tagged Expiry).
  4. At least one conditional write or transaction exercised.
  5. Cleanup commands pasted in your notes.
  6. One interview answer recorded out loud.
  • TTL hygiene → Backup/PITR for “oops” recovery.
  • Global Tables → sticky writes from capacity/hot lessons.
  • DAX → only after Query shapes are correct.
  • P1 CartLite reuses modeling + transactions.
  • P2 Social reuses adjacency + Streams ideas.

22. Quick self-check (yes/no)

  1. I can explain TTL delay vs instant DeleteItem.
  2. I know when soft-delete beats hard delete.
  3. I can start PITR and say what restore costs in time.
  4. I can name one reason NOT to use Global Tables.
  5. I know DAX does not fix a bad partition key.
  6. I can sketch CartLite USER# and ORD# keys.
  7. I can sketch a follow edge item.
  8. I delete lab replicas/DAX/backups the same day.

23. Common errors and fixes

Each row is a real mistake students and juniors hit. Read the fix before you panic.

Error / symptomFix
PITR never drilledQuarterly restore.
Restore overwrites prod nameRestore to new table.
Export = HA failoverExport is copy, not failover.
No IAM for restoreBreak-glass role.
Backup before every PutOnly risky changes.
Ignore backup storage costWatch bill.
Forget GSIs after restoreVerify indexes.
PITR on disposable labs foreverDisable when done.
RPO undocumentedWrite minutes.

24. Troubleshooting checklist

  1. PITR Enabling long: wait/describe.
  2. Backup CREATING stuck: check IAM.
  3. Restore slow: size + indexes.
  4. Missing items: wrong time restore.
  5. Bill spike: backups+PITR+export.

25. FAQ

Q. Should I always use a single table?

Often yes for related access patterns; not a religion. Separate tables are fine for unrelated domains or different capacity/security needs.

Q. Do I still need RDS?

Yes for heavy joins, multi-row SQL reports, and strong relational constraints. See the intro DynamoDB vs RDS chapter.

Q. Is Scan evil?

Scan is a tool for rare admin jobs and small tables. Design so hot paths use Query/GetItem.

Q. Where are Put/Get command details?

In the CRUD survey, CLI and SDK chapters — this deep set links them instead of copying.

Q. PITR vs backup?

PITR continuous window; backup named snapshot.

Q. Restore in place?

Creates new table; you cut over.

Q. Export replaces PITR?

No — different purpose.

Q. Cost chapter?

Yes — capacity/cost link.

26. Interview Q&A

Q. (B) PITR meaning?

Restore to a second in the continuous window.

Q. (B) On-demand backup?

Named full snapshot.

Q. (M) Restore target?

New table; cutover planned.

Q. (M) RPO?

Max acceptable data loss.

Q. (S/MNC) Drill fail reason?

Often IAM/permissions.

Q. (MNC) When export?

Analytics/offline copy — not failover.

27. Tips in English, Marathi and Hindi

Ravindra Bagale's Tip (EN)

A backup without a restore drill is a story, not a plan.

Ravindra Bagale's Tip (MR)

Restore drill नसलेला backup = story.

Tip (HI)

बिना restore drill backup सिर्फ कहानी है।

Try at home

  1. Write RPO/RTO for one table.
  2. Enable PITR on a lab; disable after.
  3. Draft a 5-line restore runbook.

In short

  1. PITR = continuous; backup = snapshot.
  2. Restore makes a new table.
  3. Drill IAM quarterly.
  4. Watch backup storage cost.

Revision, interview and comparison cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

Revision card: PITR window. No restore drill means false confidence. Enable continuous backups → restore to new table → cut over. Write RPO/RTO → enable → quarterly drill → fix IAM. Fatima Zahra failed first drill on missing IAM.
Revision card: PITR window · Download PNG · Open card page
Revision card: Named backup. Risky changes without a snapshot are gambling. create-backup before migration; list-backups; keep cost watched. Change ticket → backup name → verify AVAILABLE → proceed. Lucas Meyer snapshots ledgers before schema weekends.
Revision card: Named backup · Download PNG · Open card page
Comparison: PITR vs On-demand backup. PITR: Continuous restore to a second in ~35 days. On-demand backup: Named full snapshot you create.
Comparison: PITR vs On-demand backup · Download PNG · Open card page
Comparison: S3 export vs Table restore. S3 export: Analytics and offline copy to S3. Table restore: New table from backup or PITR.
Comparison: S3 export vs Table restore · Download PNG · Open card page
Interview card: Enable PITR. Critical tables without PITR cannot rewind. update-continuous-backups PointInTimeRecoveryEnabled=true. Lab table → enable → describe → disable/delete when done.
Interview card: Enable PITR · Download PNG · Open card page
Interview card: Restore drill. First real incident is the wrong first drill. Restore to a new lab table; verify counts; record minutes. Calendar drill → IAM role → restore → verify → notes.
Interview card: Restore drill · Download PNG · Open card page
Interview card: Export vs HA. Treating export as failover leaves you down. Export to S3 for analytics; PITR/backup for recovery. Need BI copy → export; need incident → restore path.
Interview card: Export vs HA · Download PNG · Open card page
Interview card: Write RPO/RTO. Unstated RPO makes tool choice random. RPO = loss minutes; RTO = restore minutes. Workshop numbers → map to PITR/backup → owners.
Interview card: Write RPO/RTO · Download PNG · Open card page

More cards: Ravi Sir's Cards.

Practice Tasks

About this scenario

Vidarbha Cotton Mills is a textiles business in Nagpur. Ganesh Wankhede looks after its IT and cloud work. They count money in INR and run their AWS resources in the ap-south-1 Region. In the tasks below you do real jobs for them using what this lesson teaches. All names, account IDs, IP addresses and numbers are made up for practice.

0 / 16

Easy PITR is a continuous window — 1

Why: Def.

What to do: Enter 1 if PITR lets you restore within a continuous window.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy On-demand backup is a snapshot — 1

Why: Def.

What to do: Enter 1 if on-demand backup creates a named snapshot.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Restore creates a new table — 1

Why: Restore.

What to do: Enter 1 if restore typically creates a new table.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Export is not hot failover — 1

Why: Purpose.

What to do: Enter 1 if S3 export is for copies/analytics not hot HA.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Easy Describe table

Why: CLI.

What to do: Describe table ShopApp

How:
  1. Read the task and decide which AWS service it is about.
  2. Write aws, then the service name, then the operation (the action word).
  3. Add each needed flag (--name) followed by its value from the task.
  4. Flags can be in any order. Click Check answer.

Easy Tool pick YAML

Why: Choose.

What to do: YAML: continuous: pitr, snapshot: on-demand-backup.

How:
  1. Start from the top-level keys the task names.
  2. Indent child keys with 2 spaces (no tabs).
  3. Fill in each property with the value from the task.
  4. Click Check answer. Key order does not matter.

Easy Plan cutover after restore — 1

Why: Ops.

What to do: Enter 1 if app/DNS cutover must be planned after restore.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium RPO is max data loss — 1

Why: Def.

What to do: Enter 1 if RPO is max acceptable data loss.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium RTO is restore duration target — 1

Why: Def.

What to do: Enter 1 if RTO is how long restore may take.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium Drills often fail on IAM — 1

Why: Drill.

What to do: Enter 1 if restore drills often fail on permissions.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium Backup storage costs money — 1

Why: Bill.

What to do: Enter 1 if backup/PITR storage appears on the bill.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Medium RPO RTO YAML

Why: Write.

What to do: YAML: rpo_minutes: 5, rto_minutes: 60.

How:
  1. Start from the top-level keys the task names.
  2. Indent child keys with 2 spaces (no tabs).
  3. Fill in each property with the value from the task.
  4. Click Check answer. Key order does not matter.

Hard Backup before risky changes — 1

Why: Habit.

What to do: Enter 1 if you take on-demand backup before risky changes.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Verify indexes after restore — 1

Why: Check.

What to do: Enter 1 if you verify GSIs/indexes after restore.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Disable PITR on disposable labs — 1

Why: Hygiene.

What to do: Enter 1 if disposable labs should not keep PITR forever.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

Hard Quarterly restore drill — 1

Why: Ritual.

What to do: Enter 1 if a quarterly restore drill is a good ritual.

How:
  1. Write down the numbers the task gives you.
  2. Work it out step by step on paper.
  3. Type only the final answer in the box.
  4. Click Check answer.

See all practice tasks in the Task Hub →