How to Back Up a Vector Database and Test the Restore

Teams often treat vector databases as disposable caches: if something goes wrong, just re-embed the documents. At small scale that works. With millions of chunks, re-embedding can take days, cost thousands in model calls and depend on source systems that may have changed since. A vector store that a production feature relies on deserves real backups.

Step 1: Know what you'd need to rebuild

A vector store holds more than vectors: document IDs, chunk text or references, metadata used for filtering and access control information. Record which embedding model and chunking settings produced the data, because restored vectors are only useful with the same model.

Step 2: Use the database's native backups

• PostgreSQL with pgvector: the usual tools apply, such as managed snapshots and point-in-time recovery on RDS or Cloud SQL, or pg_dump for smaller databases.
• Qdrant: create collection snapshots through its API and copy them to object storage.
• Managed vector services: check their backup and export features, and whether backups can be restored into another account or region.

For example, creating a Qdrant snapshot:

curl -X POST "http://qdrant:6333/collections/support-docs/snapshots"

Copy the resulting snapshot file to storage in another account or region.

Step 3: Schedule and retain

Back up at least daily for stores that change often. Keep a week of daily backups and a few monthly ones, and store copies outside the primary account, so a compromised account can't delete everything.

Step 4: Test the restore

A backup nobody has restored is only a hope. Every month or quarter:

1. Restore the latest backup into a separate environment.
2. Compare document and vector counts with production.
3. Run your retrieval benchmark queries and compare the results with production.
4. Record how long the restore took.

The restore time tells you whether your recovery objective is realistic.

Step 5: Keep a rebuild path as well

Backups cover sudden loss. Keep the ingestion pipeline working too, so you can rebuild from source if backups turn out to be corrupt or you need to change embedding models.

Things to watch

• Consistency with source data. A restored index may reference documents deleted since the backup. Run a sync after restoring.
• Permissions metadata. Restoring an old copy can bring back old access rules. Re-apply current permissions before serving results.
• Encryption keys. Encrypted backups are useless if their keys can't be recovered too.

Run one restore test this month and write down how long it took.