Collection snapshots scope the backup to one collection; full storage snapshots cover the whole single-node storage state
A collection snapshot is scoped to one collection on a specific node. It contains that collection's configuration and data, including its points and payloads, and is the right choice when I need to migrate or recover only one collection. A full-node or full-storage snapshot is broader: it represents the node's whole Qdrant storage, including all collections and collection aliases. The operational distinction matters because full-storage snapshots are only suitable for single-node deployments according to Qdrant's current documentation; they are not the mechanism for reconstructing a distributed cluster. A common misconception is that a full-node snapshot is simply a larger version of a collection snapshot with the same restore semantics. The scope and supported deployment model are different, and cluster-level backup/recovery mechanisms may be preferable for managed/cloud deployments.
Collection snapshot: narrow scope, useful for moving or restoring one collection.
Full storage snapshot: broader scope, covering all collections and aliases on the single-node instance.
Trade-off: full storage snapshots simplify whole-instance recovery but create larger backup artifacts and are less selective.
Qdrant's current documentation says full storage snapshots are suitable only for single-node deployments; for distributed systems, collection snapshots are taken per node, while cloud backup products provide another cluster-level recovery option.
You have five collections but need to migrate only one of them. Which snapshot scope is more appropriate?
A single-node Qdrant server hosts several unrelated collections and you want a complete instance backup. Which snapshot type fits?
Your production node is single-node today but may become distributed later. How would you avoid building a backup process that only works for today's topology?
A team restores a full-storage snapshot just to recover one deleted collection. What operational downside does that introduce?
You are migrating one collection from a multi-node source cluster to a separate cluster. How would the snapshot strategy differ from a single-node migration?
Your organization wants one backup format that works identically for both single-node and distributed deployments. What assumption would you challenge?
Design a backup architecture that supports a single-node development environment, a distributed production cluster, and Qdrant Cloud without conflating their restore mechanisms.
How would you map backup scope to recovery objectives when teams need both per-collection rollback and full-cluster disaster recovery?