Configuring DynamoDB Backup and Recovery with Clumio 

Clumio provides SaaS-based, agentless backup for data stored in AWS. For DynamoDB, Clumio combines SecureVault backups stored in Clumio’s air-gapped, immutable vault outside of your AWS account with optional Clumio-managed AWS snapshots and continuous backups for PITR. SecureVault backups exist outside of the source account, meaning that they are designed to remain recoverable even if the account itself is compromised.

Rather than applying a policy bucket by bucket or table by table, Clumio uses protection rules. These consist of a set of conditions – for instance account, region, or tag – that determine which backup policy applies to which tables. Tag-based rules mean that any table you create in the future with a matching tag is automatically protected, with no manual step required.

My DynamoDB Employees table is tagged dept=hr. I’ll create a new backup policy and protection rule that automatically protects any table tagged dept=hr.

1) Navigate to Protect, Backup policies, and click Create.

Creating a backup policy 

2) Name the policy something that reflects the workload, like hr-dynamodb-policy, and select DynamoDB from the Add asset types menu.

Selecting an asset type for the policy

3) On the Configure DynamoDB screen, set the SecureVault backup frequency and retention. DynamoDB requires a minimum of one backup every 6 hours with 1-day retention, and I’ll set retention to 30 days for this policy. There’s also the option to configure weekly, monthly, and yearly backups, each with their own retention periods.

4) Set the time you want the backup to start, and choose a backup destination for SecureVault. By default, backups are stored in-region. However, a different region can be selected if you need geographic separation from the source table. Note that transfer charges will apply if you store backups in a different AWS region. There’s no 35-day limitation, and the SecureVault backups persist even after the source table is deleted in AWS.

5) Optionally, enable Clumio-managed AWS backup if you also want native AWS-side backups retained on your own schedule.

Configure backup frequency and retention.

6) Click Add, review the summary, and click Save to save the policy.

1) Navigate to Protect, AWS Protection Rules, and click Create Protection Rule.

Create a protection rule for the new policy.

2) Name the rule, for example hr-dynamodb-rule, and select DynamoDB as the asset type.

3) Under Tag, add a condition to include assets with a Key of dept and Value of hr. Note that tags are case-sensitive, so type the tag exactly as it appears in your AWS account; otherwise, Clumio will not find your table.

Configure the protection rule.

4) Under Policy, select the hr-dynamodb-policy policy, and click Next.

Select the backup policy.

5) Set the rule priority and click Next. Priority decides which rule wins if a table matches more than one rule. A table can only be covered by one rule at a time.

Configure the rule priority.

6) After reviewing the summary, click Preview Assets to confirm which tables the rule will match. The Employees table should appear in the list, since it’s tagged dept=hr. Then click Create Rule.

7) Check the configuration by clicking AWS, Inventory, DynamoDB Tables.

Check the configuration.

8) The Employees table should appear in the inventory, and after a few minutes the first backup is initiated.

The Employees table has been added to the inventory.

For a quick walkthrough, watch this 4-minute demo to see how to apply backup policies to DynamoDB tables using Clumio protection rules.

The team has flagged that the Customers table has become corrupted and data has been lost. The inventory above shows that Customers already is covered by an existing protection rule, which applies the prod-dynamodb policy to the table.

As the table is being protected by Clumio, I just need to initiate a restore.

The Customers table contains corrupt data.

1) Navigate to AWS, Inventory, DynamoDB Tables, and click Customers to open its asset details page and backup calendar.

The backup calendar for the Customers table

2) Since the corruption happened recently but I want a known-good copy, I’ll go back to a SecureVault backup from before the corruption occurred.

3) Click on the date of the backup to use. This displays the backup details for that date, including links to the latest SecureVault backup.

Click on the date to display the backups available.

4) I’ll choose a SecureVault backup Full restore. By default, it is designed to create a new DynamoDB table and restore the data to the new table, although you can choose to restore to your original table.

5) View the progress of the restore by clicking Tasks.

Restore in progress

6) After the task shows as completed, the restored table is available in DynamoDB.

The restored table in DynamoDB

7) From here, the team can validate the records and, if it checks out, either point the application at the restored table or copy the corrected data back into the original Customers table.

Corrupt data is recovered.

Clumio also offers Backtrack for DynamoDB, which enables in-place, partition-level PITR when you need to roll back part of a table rather than perform a full restore.

With a policy- and a tag-based protection rule in place, new tables are protected automatically the moment they’re tagged. No manual step is required for new tables. When data loss happens, SecureVault is designed so that you can recover from a known-good backup in a handful of clicks rather than scrambling to reconstruct data from application logs.

The best time to test this is before you need it. Tag your critical tables today, confirm your protection rules are catching them, and run a practice restore so the process is easy and familiar.

To get started today, request a demo or two-week free trial.