1. Three strategies
| Strategy | RPO | RTO | Cost | Notes |
|---|---|---|---|---|
| Rebuild from source in DR | Source replication lag | Hours to days (embedding throughput) | Low standby cost; embedding tokens at recovery | Needs source docs + pipeline + quota in DR |
| Snapshot and restore | Snapshot interval | Minutes to hours (restore size) | Storage for snapshots | Must match the engine version and embedding model |
| Replicate / dual-write | Seconds to minutes | Minutes | Running a second index all the time | Active-active or warm standby |
2. Estimate the rebuild time
embedding time ≈ total tokens to embed ÷ (TPM quota in DR × usable fraction)
Example: 4 million chunks × 400 tokens = 1.6 billion tokens. With 1 million TPM usable in DR: 1,600 minutes, which is about 27 hours (plus parsing and indexing). If that's beyond your RTO, you need snapshots or replication.
Keep embeddings with the chunks in a store you replicate (Parquet in object storage, or a database table), so a rebuild can reload vectors without re-embedding. This cuts rebuild time to the indexing time only.
3. Snapshot commands
| Engine | Snapshot | Restore |
|---|---|---|
| Qdrant | POST /collections/{name}/snapshots (or a full-storage snapshot) | PUT /collections/{name}/snapshots/recover |
| Milvus | Milvus Backup tool (milvus-backup create) to object storage | milvus-backup restore |
| Weaviate | POST /v1/backups/{backend} (S3/GCS/Azure modules) | POST /v1/backups/{backend}/{id}/restore |
| pgvector | Database backups (pgBackRest, managed PITR) | Database restore |
| OpenSearch / Elasticsearch | PUT _snapshot/repo/snap-1 to a repository in object storage | POST _snapshot/repo/snap-1/_restore |
| Azure AI Search | No built-in index backup: rebuild from source with indexers, or export and import documents (including vectors) with your own tool | Re-index |
| Bedrock Knowledge Bases | Managed: recreate the KB with IaC and sync from the replicated S3 bucket | Sync |
Store snapshots in DR-region object storage (or cross-region replicated buckets).
4. Replication options
- Dual-write from the ingestion pipeline: the queue fans out to the primary and DR indexes. Simple, and works across any engine.
- Engine features: cross-cluster replication (OpenSearch / Elasticsearch CCR), PostgreSQL streaming replicas for pgvector.
- Monitor the document count and last-update timestamp in both indexes, and alert on drift.
5. Keep the embedding model consistent
Vectors only work with the same embedding model and version that created them. In DR:
- Deploy the same embedding model and version.
- Record the model name and version in the index metadata (or the collection name, for example
kb_docs__te3small_v1). - A provider retiring an embedding model forces a full re-embed. Plan it like a migration (see the embedding model migration post).
6. Recommended defaults
| Corpus size | Default |
|---|---|
| < 100k chunks | Rebuild from source (fast enough) |
| 100k–10M chunks | Stored embeddings + snapshot every 4–24 h |
| Critical, large | Dual-write to a warm DR index |
Tip
Test the restore with a search quality check, not only a document count. Run 20 golden queries and compare top-5 results to production. A restore with the wrong distance metric or an old embedding model "works" but returns poor results.