Skip to content

Backup & restore

fdyno implements DynamoDB's backup and restore APIs on top of FoundationDB. The API surface enforces the same validation rules as DynamoDB; the storage semantics are adapted to what FoundationDB provides natively.

On-demand backups

CreateBackup writes a point-in-time consistent snapshot of the table to dynodb_backups/<arn>/ in FoundationDB. It pins a single FoundationDB read version and reads the whole table at that version across as many bounded transactions as needed, so the snapshot is internally consistent even for tables larger than a single transaction can hold. Small metadata (item count, size, TTL specification) is stored separately from the item data, so ListBackups, DescribeBackup, and DeleteBackup are constant-time regardless of table size, and DescribeBackup reports the real BackupSizeBytes and SourceTableDetails.TableSizeBytes. CreateBackup is idempotent on the same backup name.

RestoreTableFromBackup reads a backup and rehydrates a new table at its own directory, writing items across bounded transactions. Indexes, tags, deletion protection, table class, and the stream specification are preserved; billing mode and GSI/LSI definitions can be overridden at restore time. A small table is restored in a single atomic transaction; a larger one is written in batches and briefly reports CREATING before becoming ACTIVE.

flowchart LR
    B["CreateBackup"] --> R["dynodb_backups/&lt;arn&gt; · metadata · chunked items"]
    R --> RT["RestoreTableFromBackup"] --> NT["new table directory"]

Snapshot consistency and scale

A backup is consistent as of a single pinned FoundationDB read version. Because FoundationDB's MVCC read window defaults to roughly five seconds, the consistent snapshot is bounded by how much can be read in that window; a snapshot that cannot finish in time fails with a clear ValidationException rather than producing an inconsistent backup. For consistent backups of very large clusters, use FoundationDB's native backup tooling (fdbbackup) at the cluster level.

Point-in-time restore (PITR)

RestoreTableToPointInTime exposes DynamoDB's PITR API and applies its validation rules:

  • source resolution by ARN or name,
  • UseLatestRestorableTime xor RestoreDateTime,
  • the 35-day restore window bounds,
  • PITR-enabled gating via PointInTimeRecoveryEnabled,
  • and target-table uniqueness.

Snapshot-on-restore semantics

fdyno uses snapshot-on-restore: a PITR restore reads the source table's current committed state at restore time, consistently at a single pinned read version (the same mechanism as CreateBackup). True time-travel to an arbitrary past instant is out of scope, because FoundationDB's MVCC read window defaults to roughly five seconds, far below DynamoDB's 35-day retention. The API validation is faithful; the data returned is the latest snapshot, not a historical one.

Both restore APIs apply billing-mode and index overrides through the same validation, so they behave identically.

Continuous backups & PITR status

DescribeContinuousBackups and UpdateContinuousBackups report and toggle PITR status. When PITR is enabled, the description includes the documented EarliestRestorableDateTime and LatestRestorableDateTime window, matching what a DynamoDB client expects when rendering a recoverable range.