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 backup record (table metadata, an item snapshot, and the
TTL specification) to dynodb_backups/<arn>/ in FoundationDB. It is idempotent
on the same backup name.
RestoreTableFromBackup reads a backup record and rehydrates a new table at
its own directory. Indexes, tags, deletion protection, table class, and the stream
specification are preserved; billing mode and GSI/LSI definitions can be
overridden at restore time.
flowchart LR
B["CreateBackup"] --> R["dynodb_backups/<arn> ยท metadata + items + TTL"]
R --> RT["RestoreTableFromBackup"] --> NT["new table directory"]
Point-in-time restore (PITR)¶
RestoreTableToPointInTime exposes DynamoDB's PITR API and enforces every
DynamoDB-side rule:
- source resolution by ARN or name,
UseLatestRestorableTimexorRestoreDateTime,- 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. 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.
A shared helper validates and applies billing/index overrides identically for both restore APIs, so the two paths cannot drift apart.
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.