A snapshot is a point-in-time archive used for backup and migration
I think of a Qdrant snapshot as a point-in-time archive of a collection's data and configuration, including its stored points and pre-built index. In production it has two common uses: first, disaster recovery or rollback to a known-good state; second, moving or cloning a collection between environments without rebuilding the vector index from scratch. The second use is important on large collections because restoring a snapshot can avoid the expensive re-indexing phase. I would not treat a snapshot as the same thing as a full disaster-recovery strategy for every deployment: for Qdrant Cloud, full-cluster backups are a separate mechanism aimed at cluster failure recovery. A common misconception is that a collection snapshot automatically represents an entire distributed cluster; in a distributed setup, snapshots are node-specific for the collection, so recovery needs the appropriate snapshot set.
Backup use case: keep a known-good point-in-time copy for recovery after accidental deletion, corruption, or a bad data update.
Migration use case: move or clone a Qdrant collection while preserving its pre-built index, avoiding a full re-index on the destination.
Trade-off: snapshots are convenient for collection movement and recovery, but they require compatible Qdrant versions and enough temporary storage during restore.
Current Qdrant documentation states that a collection snapshot contains collection data, configuration, points, and payloads; collection aliases are not included. Snapshot restore compatibility is version-sensitive, so production procedures should pin and test Qdrant versions.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience