AWS DynamoDB Support
DynamoDB point-in-time recovery and restore.
DynamoDB is durable, but that does not protect you from a bad deploy or an accidental delete. Point-in-time recovery and backups let you restore, but a restore creates a new table and does not carry every setting. We enable the protection, rehearse a restore and write down what to rebuild.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Someone deleted items, or a bug wrote bad data to a table
- A table was dropped or a migration went wrong
- You have not enabled PITR on production tables
- An audit requires backup evidence and tested restores
- You need cross-Region or cross-account backup copies
What you get
- Protection audit for every table
- PITR and AWS Backup configuration in infrastructure as code
- A tested restore runbook with timings and a post-restore checklist
- Scripts for item-level repair from a restored table
How we do it
A clear, safe process you can follow along with.
1. Audit what is protected
We check each table for PITR status, existing backups and any AWS Backup plans. Tables without PITR have only on-demand backups, if any.
2. Enable PITR and set up scheduled backups
We turn on PITR for production tables and add AWS Backup plans for retention rules, copies to another Region or account, and vault locking where required.
3. Restore to a new table
A restore always creates a new table. We pick a timestamp just before the bad event, using application logs or CloudTrail to find it, and restore the table with its indexes.
4. Rebuild what the restore does not copy
Auto scaling settings, IAM policies, CloudWatch alarms, stream configuration, TTL settings and tags may need to be recreated. We keep these in infrastructure as code so this is quick.
5. Repair production data
Rather than swapping tables, we usually copy the missing or corrected items back from the restored table with a script, or repoint the application when a full swap is needed.
6. Rehearse and time it
We run a restore drill, record how long it takes for your data size and update the recovery runbook with real numbers.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Assuming durability equals backup
Replication within DynamoDB copies deletes and bad writes too.
Expecting an in-place restore
A restore produces a new table, so the application must be repointed or data copied back.
Forgetting the settings that do not restore
Alarms, scaling and some table options must be recreated.
Frequently Asked Questions
How long can I restore a DynamoDB table back with PITR?
You can choose a recovery period of up to 35 days. Restores can target any second within that window.
Does DynamoDB restore overwrite the existing table?
No. Restore creates a new table, and you decide whether to repoint the application or copy items back.
Does PITR cost extra?
Yes, PITR is billed on table size. Check current regional pricing and weigh it against the cost of data loss.
Want Help With DynamoDB point-in-time recovery and restore?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required