FaunaDB Backup Restore ↔︎ Index Rebuild Timing: Uncertain Warm‑Up Period

Direct Answers

1. Index rebuilding: Yes. FaunaDB restores recreate the database state from the snapshot, which includes all index definitions and their data. Indexes are rebuilt automatically as part of the restore operation; no separate manual step is required.

2. Warm‑up period: No documented warm‑up period exists. Once the restore operation signals completion, indexes are immediately queryable. The first few queries on a large dataset may exhibit higher latency while the distributed cache populates, but this is a caching effect, not an index rebuild.

3. Validation approach: FaunaDB does not provide a native checksum or integrity‑comparison tool. Verification is a client‑side responsibility. The standard pattern is to run count queries on primary indexes and sample high‑cardinality keys on both the source and restored instances, then compare results.

Verification Steps

1. Trigger a backup of the source database and restore it to a new test instance using fauna backup restore.
2. Wait for the restore operation to report completion.
3. Immediately execute a Get request against a known index (e.g., Index.all() or a specific term lookup) to confirm the index is online.
4. Run a Count query on a primary index in both the source and restored databases. The counts must match exactly.
5. Optionally, sample a set of high‑cardinality keys (e.g., random document IDs) and verify that Get returns identical data on both instances.

Assumptions and Uncertainty

• Behavior described applies to FaunaDB’s managed cloud service as of 2026; self‑hosted or enterprise variants may differ.
• The “initial latency” observation is based on distributed‑system caching characteristics, not a documented FaunaDB guarantee. Mark for review if your workload is latency‑sensitive.
• No built‑in integrity hash is exposed; if regulatory audit trails require cryptographic proof, you must implement an application‑level checksum (e.g., hash of sorted document IDs) before and after restore.

One Diagnostic Detail That Changes the Recommendation

If the restored database will serve production traffic immediately, confirm whether your client driver’s connection pool targets the new endpoint before the first query. A stale endpoint will return “database not found” errors that can be mistaken for index unavailability.