Algolia Backup Restore vs. Manual API Re-indexing for Data Recovery

When recovering a corrupted or accidentally deleted index in Algolia, there are two primary documented paths: utilizing the managed Backup and Restore feature or performing a full manual re-index from the primary source of truth via the API.

The managed restore is a server-side operation that minimizes data transit and latency. However, it restores the index to a specific point in time, potentially introducing stale data if the primary database has evolved since the snapshot was taken. Conversely, manual re-indexing ensures the search index reflects the current state of the source database but consumes API quota and requires significant client-side bandwidth for large datasets.

For an environment where data consistency with the source of truth is critical but recovery time objectives (RTO) are tight, the trade-off between speed and freshness is unclear.

• Does the Backup and Restore feature allow for partial record recovery, or is it strictly an all-or-nothing overwrite?
• In cases of massive datasets, is there a documented method to reconcile the delta between a restored backup and the current source of truth without a full re-index?