Amazon DynamoDB backup and recovery

Three options: an exact PITR timestamp, a Snap, or a SecureVault backup point.

 From individual records up to entire tables.

 Restore back into the source table, into an existing empty table, or land somewhere else entirely.

DynamoDB PITR is tied to the source table: if the table is deleted (accidentally or maliciously), the PITR window goes with it. PITR also doesn’t support cross-account restore. AWS Backup keeps logically separate copies, but every copy is a full backup, so storage cost grows linearly with retention. SecureVault sits in an immutable, air-gapped vault outside your AWS account. The backup survives even if the source table or source account is compromised and supports cross-account and cross-region restore. Customers running Clumio for DynamoDB have reported up to ~50% lower TCO vs. AWS Backup, mostly because SecureVault is incremental-forever after the seed instead of taking repeated full backups. 

When 15-minute RPO is selected on the policy, Clumio uses Amazon DynamoDB Streams to capture incremental changes between scheduled backups. You can then restore to any timestamp inside the retention window, not just the next scheduled capture. Streams must be enabled on the table for this to work. 

Clumio enforces an hourly SLA on SecureVault: at least one backup attempt per hour, regardless of policy schedule. The default policy is one backup every 6 hours retained for 3 days. You can tighten or loosen both per workload, but Clumio will continue to attempt hourly captures under the SLA. Clumio-managed Snaps are independent and follow whatever schedule and retention you configure on the policy; they’re taken by AWS and stored in your account. 

Yes. Cross-account and cross-region restore are both supported for DynamoDB SecureVault backups. Pick the target account and region during restore setup. The target account must have a Clumio connector installed and trust established. Because backups live outside the source account, there’s no dependency on the source account being healthy, which is useful for ransomware and account-compromise recovery scenarios.

Three levels. Record: query Item Collections from a SecureVault backup with a partition key (required) and sort key (optional), apply attribute filters, preview the matched records, and either download as CSV or share a download link via Transparent Data Access with a passcode for the recipient. Partition: roll selected partitions back in place via Backtrack using partition_key and sort_key filters. Full table: restore the entire table from any SecureVault backup or Snap, in place or out-of-place. Pick the smallest level that fits the recovery. Record-level avoids rehydrating the whole table when you only need a subset of items. 

Backtrack restores the source table itself (or selected partitions of it) back to a previous point-in-time, in place. Two flavors: full-table Backtrack returns the entire table to a chosen timestamp, and partial Backtrack uses partition_key and sort_key filters to roll back only the affected partitions, leaving everything else untouched. Both preserve the table ARN, IAM bindings, and Terraform state, so downstream resources don’t need rewiring. Arbitrary-timestamp Backtrack depends on the configured RPO. With 15-minute RPO, you can target any instant; with a coarser policy schedule, Backtrack still works against captured points on the calendar.

Either, depending on which restore type you pick. Backtrack is in-place: it modifies the existing table. Full and partial restores can land in a brand-new table or, more usefully for Terraform/IaC users, into an existing empty table as long as the schemas match. That second option avoids leaving orphaned tables that aren’t tracked by your IaC state. 

SecureVault backups are stored in Clumio’s immutable, air-gapped vault outside your AWS account; they’re the right call for ransomware, account compromise, and long-retention scenarios, and they’re what Backtrack and record-level granular restore operate against. Clumio-managed Snaps are native AWS snapshots taken by AWS and stored in your AWS account, managed from the Clumio console; they’re fast for operational recovery but live in the same security sphere as the source table. A single Clumio policy can drive both. If you edit Snap frequency or retention from the AWS console directly, those changes override the Clumio policy settings, so manage Snap schedules from one place.