Backing Up a RAG Assistant: What to Save in S3, PostgreSQL and Qdrant, and What to Rebuild

⚡ The Gist in 5 Seconds

• Mikhail Vitko from Reg.ru Cloud broke down what to back up in a RAG assistant: S3, PostgreSQL and Qdrant in Kubernetes.
• The unit of recovery is a consistent set: document versions, metadata, the index, code versions and model versions.
• Failures can be silent: the service is alive and responding, but off the old index it says '14 days' instead of '30'.

🔍 What Happened

Runity's blog on Habr has published the first part of a piece by Mikhail Vitko, PaaS product manager at Reg.ru Cloud, on backing up an AI assistant for corporate documents. The walkthrough is built on a specific architecture: source files in S3, DBaaS PostgreSQL storing document versions, application-level permissions and conversation history, and the API and handlers running in KaaS. The team deploys Qdrant itself — as a StatefulSet with PVCs and a Persistent Volume in the same Kubernetes. Answers are generated by an external LLM via API, and embeddings are computed by a separate model.

The RAG mechanics are laid out step by step: when a document is uploaded, the handler stores the source file, extracts the text, splits it into chunks and computes embeddings. When a question comes in, the app finds the chunks the user is allowed to see and hands them to the language model. Components update independently, and that's the root of the problem: the file is already in S3 but the vectors aren't all there yet; the database knows the new revision of a policy, while the index still holds the previous one. The author gives a vivid example: after a restore, the assistant answers that the product return window is '14 days' instead of '30'. An availability check won't catch a gap like that.

Next comes inventory. Embeddings and the index are different levels: saved vectors let you rebuild the search structure without calling the model, while if only the PDFs remain, you'll have to re-extract the text, re-chunk it and re-vectorize. A provider's model usually can't be copied, so what gets saved instead is the model identifier, request parameters, prompts and tests. Conversation history is backed up with stable conversation_id, message_id, message ordering and roles.

🧠 Our Take

Our assessment: this is a rare case of a vendor writing not about 'we launched yet another service' but about where AI applications actually break. The assistant isn't a monolith but several stores updating at different rates. The classic 'single database' backup gives false peace of mind here.

The second point is money and time. Fully re-vectorizing the corpus costs money on embedding calls and hours of downtime, while storing vectors is cheaper. We believe the debate isn't 'to back up or not to back up' but about what the team is willing to rebuild and what it must keep.

Who wins: those who version documents and the index together. Who loses: those who treat Qdrant as 'the application's internal business' and never check consistency after a restore. A separate trap is the external model's version: once the provider pulls it, even a full backup won't bring back the old behavior.

⚠️ What We Don't Know

The piece has no numbers: no corpus sizes, no RPO/RTO, no comparison of the cost of storing vectors versus rebuilding. The second part — on recovery and verification — hasn't been published yet, so we haven't seen the recipe for a consistent rollback. And it's a vendor blog: the architecture is tied to the vendor's own services, and Qdrant in the example is the application team's responsibility, not the cloud's.