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 Amazon DynamoDB and the best use cases for each.
DynamoDB point-in-time recovery
DynamoDB point-in-time recovery (PITR) is a fully managed continuous backup feature built into DynamoDB. Once enabled, PITR allows you to restore your table to any point in time during the last 35 days with per-second granularity. PITR backups are system level and are held in an AWS managed account. Even if your account is compromised, an unauthorized user cannot delete this backup. You can enable PITR from the AWS Management Console, AWS SDKs, or the AWS Command Line Interface (AWS CLI), as in the following example:
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 AWS Command Line Interface (AWS CLI), some source table-level settings aren’t automatically applied to the newly created table. These include auto scaling, streams, Time to Live (TTL), and more. Refer to Automate update of table settings on restored Amazon DynamoDB table for an event-driven solution to automatically apply Amazon DynamoDB table settings to a restored table using AWS CloudFormation templates.
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 Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR).
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 restore individual backups to new tables using the service APIs or console. When you restore to a new table, DynamoDB lets you keep or change settings such as global secondary indexes (GSIs), local secondary indexes (LSIs), or encryption settings.
To create an on-demand backup, you can use the console, the AWS SDK for the programming language of your choice, or the AWS CLI. The following is a basic example of an AWS CLI command to create an on-demand backup:
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 AWS Backup, a fully managed and centralized data protection service. You can use AWS Backup to create and manage backup schedules for your DynamoDB tables. AWS Backup enables cross-account backups, which provide extra protection by allowing backups to be copied to other AWS accounts. Additionally, if you have backups that need to be retained long term for compliance requirements, you can take advantage of cold storage for cost savings.
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 AWS accounts, such as a development or test account
You want to copy or migrate your data to a different AWS 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 AWS Backup in conjunction with PITR to meet this requirement. You can use AWS 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 AWS 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 Working with On-Demand backup and restore and Working with point-in-time-recovery
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 Zamborsky is a Solutions Architect at Amazon Web Services based in Seattle, WA. He works with nonprofit research customers. He loves candles.
Read MoreAWS Database Blog
