We use machine learning technology to do auto-translation. Click "English" on top navigation bar to check Chinese version.
Backup strategies for Amazon DynamoDB
One of the most important questions when discussing databases is “How will we backup and restore our data?” Backups are a central component of any disaster recovery strategy and are primarily governed by your Recovery Point Objective (RPO) and Recovery Time Objective (RTO). You want to make sure your backup strategy supports your needs with minimal administration, doesn’t interrupt your business, and is cost-effective. In this post, we review the various backup strategies you can use with
DynamoDB point-in-time recovery
DynamoDB
Note that PITR is not retroactive when enabled. The earliest available restore point is the time that you enabled PITR.
Although PITR enables you to restore a table to a point in time using the DynamoDB console or the Amazon Web Services Command Line Interface (Amazon Web Services CLI), some source table-level settings aren’t automatically applied to the newly created table. These include auto scaling, streams,
PITR greatly minimizes the risk of losing data and is useful for workloads that are sensitive to data loss because it protects you from accidental deletes and writes on your table. Per-second granularity makes it easy to achieve stringent RPOs. When looking at alternatives such as scheduled backups, you can only recover to the last backup point, which can mean hours of data loss. For an overview of PITR, see
DynamoDB on-demand backups
On-demand backups enable you to tell DynamoDB to initiate full table backups without impacting the performance of the table. You can
To create an on-demand backup, you can use the console, the
Many workloads require scheduled backups to be taken at a specific time every week or day, which at first glance might not seem to be a feature of on-demand backups. To achieve scheduled DynamoDB backups, you can use
The following are some scenarios that are a good fit for on-demand backups:
- Regulatory compliance requires you to retain data for more than 35 days, such as retaining data for 7 years per U.S. Securities and Exchange Commission requirements
- You need to copy a table between Amazon Web Services accounts, such as a development or test account
- You want to copy or migrate your data to a different Amazon Web Services Region
How to choose between PITR and on-demand backups
Let’s consider a few different DynamoDB workloads:
- Workload 1 – A DynamoDB table that powers a web application with an RPO of 45 minutes and a data retention requirement of 30 days.
- Workload 2 – A DynamoDB table that powers a financial services application with an RPO of 15 minutes and a compliance requirement to retain data for 7 years.
- Workload 3 – A DynamoDB table that powers a research application. The data in the table is unchanging, because it’s used as a lookup table to support the simulation runs performed by the research application. Because the data is unchanging, there is no RPO, but the data is expensive to recreate, so a backup is still required.
In the first workload, PITR can meet the entire backup requirement. Because PITR has per-second granularity and a 35-day retention period, the 45-minute RPO and 30-day retention requirement are easily met. The second workload is a bit more complicated. Enabling PITR will meet the RPO, but not the 7-year retention requirement. Here, you can use Amazon Web Services Backup in conjunction with PITR to meet this requirement. You can use Amazon Web Services Backup to schedule on-demand backups and retain them for 7 years, storing them in cold storage for cost savings. The third workload can be accomplished with a single on-demand backup, because the data is unchanging.
From these examples, we can see some general guidelines:
- For most tables, especially those with a low RPO requirement, you should use PITR
- If you have a low RPO but also need to retain copies longer than 35 days, use on-demand backups with Amazon Web Services Backup in conjunction with PITR
Conclusion
In this post, you learned about different methods to back up your DynamoDB tables to help you meet your backup and compliance requirements. To learn more, refer to
We encourage you to use this post as a jumping-off point for evaluating your DynamoDB backup strategy, and invite you to leave your questions or comments in the comments section.
About the Author
Ted Za m borsky is a Solutions Architect at Amazon Web Services based in Seattle, WA. He works with nonprofit research customers. He loves candles.
The mentioned AWS GenAI Services service names relating to generative AI are only available or previewed in the Global Regions. Amazon Web Services China promotes AWS GenAI Services relating to generative AI solely for China-to-global business purposes and/or advanced technology introduction.