Snapshots can be grouped by where they are created, how consistent they are, and how they are used for recovery.
Common snapshot types include storage snapshots, filesystem snapshots, database snapshots, backup snapshots, index snapshots, full snapshots, incremental snapshots, crash-consistent snapshots, and application-consistent snapshots.
Short Answer
The main types of snapshots are storage-level, filesystem-level, database-level, application-level, index-level, full, incremental, crash-consistent, and application-consistent snapshots.
Each type captures point-in-time state at a different layer.
The right type depends on whether the goal is fast rollback, disaster recovery, database restore, search index recovery, migration, or test environment cloning.
Storage Snapshots
Storage snapshots are created by the disk, block volume, storage array, or cloud storage platform.
They capture the state of storage blocks at a point in time.
Storage snapshots are often fast and space-efficient, but they may not understand database consistency unless coordinated with the database.
Filesystem Snapshots
Filesystem snapshots capture the state of files and directories at a point in time.
They are useful for rollback, file recovery, and cloning environments.
For databases, filesystem snapshots should be used carefully because the database may have in-memory state, write-ahead logs, or active background processes.
Database Snapshots
Database snapshots capture database state rather than only raw storage state.
They may include tables, collections, indexes, schema, transaction log position, metadata, or database manifests.
Database snapshots are usually safer for database recovery than uncoordinated storage snapshots.
Backup Snapshots
Backup snapshots are snapshots used as part of a backup and restore workflow.
They are stored, retained, protected, monitored, and restored according to a recovery policy.
A snapshot becomes backup-grade only when it can restore the system after the original environment is lost or no longer trusted.
Application Snapshots
Application snapshots are created at the application or service layer.
They may export application records, configuration, search documents, user state, or business objects in a portable format.
They are useful for portability but may require rebuilding database indexes after restore.
Index Snapshots
Index snapshots capture the state of an index structure.
In vector databases, an HNSW index snapshot can reduce startup time by loading recent nearest-neighbor index state and replaying fewer write-ahead log entries.
Index snapshots improve recovery speed, but they are not automatically full database backups.
Vector Index Snapshots
Vector index snapshots are a specialized form of index snapshot.
They capture the graph, partition, centroid, or other index state used to accelerate nearest-neighbor search.
They are valuable when rebuilding the index from scratch would be slow, especially for large collections.
Full Snapshots
A full snapshot captures a complete recovery point for the selected scope.
It is simpler to reason about because restore does not depend on a chain of earlier snapshots.
The trade-off is storage size and capture cost.
Incremental Snapshots
An incremental snapshot stores only changes since a previous snapshot or backup.
Incremental snapshots reduce backup size and duration when most data has not changed.
The trade-off is dependency: base snapshots and intermediate snapshots must remain available for restore.
Differential Snapshots
A differential snapshot stores changes since a full base snapshot.
It does not usually depend on every previous differential snapshot in the way a chained incremental sequence might.
This can simplify restore at the cost of larger snapshots over time.
Crash-Consistent Snapshots
A crash-consistent snapshot captures data as if the system lost power at that moment.
The database or application must recover using its own logs and crash recovery mechanisms after restore.
This can be acceptable for systems designed around durable write-ahead logs, but it still needs restore testing.
Application-Consistent Snapshots
An application-consistent snapshot coordinates with the application or database before capture.
It may flush writes, pause unsafe operations, mark log positions, or quiesce the service briefly.
This type is usually safer for production database backups than a raw crash-consistent snapshot.
Point-in-Time Snapshots
Point-in-time snapshots preserve a recovery point from a specific moment.
They are useful when recovering from accidental deletion, bad migrations, corrupted imports, or faulty application releases.
The snapshot schedule determines how close the recovery point is to the incident.
Local Snapshots
Local snapshots are stored near the system they protect.
They can be useful for fast rollback, but they may fail with the host, disk, node, or cluster.
Local snapshots should not be the only disaster recovery mechanism.
Remote Snapshots
Remote snapshots are copied or created in external storage.
Examples include object storage, cloud blob storage, cross-region storage, or a backup repository.
Remote snapshots are more useful for disaster recovery because they survive more failure scenarios.
Immutable Snapshots
Immutable snapshots cannot be changed after creation.
They help protect recovery points from accidental modification, corruption, or some destructive actions.
Immutability is especially useful for backup retention and compliance workflows.
Scheduled Snapshots
Scheduled snapshots are created automatically at regular intervals.
They help enforce recovery point objectives without relying on manual action.
Schedules should be paired with monitoring so failed snapshot jobs are noticed quickly.
Manual Snapshots
Manual snapshots are created by an operator before a risky task.
They are useful before upgrades, schema changes, destructive cleanup, bulk imports, migrations, or reindexing.
Manual snapshots are not a replacement for scheduled recovery coverage.
Snapshots in Vector Databases
Vector databases may use several snapshot types at once.
A storage snapshot might protect disk state. A database backup snapshot might capture collections and metadata. An index snapshot might reduce startup time for the vector index.
The recovery plan should define which type protects objects, vectors, metadata, schema, indexes, tenants, and access controls.
How to Choose
Choose the snapshot type based on the recovery problem.
- Use storage snapshots for fast infrastructure rollback.
- Use database snapshots for database-aware recovery.
- Use backup snapshots for disaster recovery.
- Use index snapshots to reduce startup or rebuild time.
- Use application snapshots for portable exports.
- Use incremental snapshots to reduce backup size and duration.
Validation
Every snapshot type needs restore validation if it is part of recovery.
For databases, validate startup, schema, records, logs, indexes, permissions, and application queries.
For vector databases, also validate vector search results, metadata filters, tenant isolation, and retrieval quality.
Common Mistakes
Common mistakes include:
- assuming storage snapshots are database-consistent
- confusing index snapshots with full backups
- using only local snapshots for disaster recovery
- deleting base snapshots needed by incremental snapshots
- not testing restore
- omitting metadata, schema, tenants, or access controls
- keeping snapshots without a retention policy
Summary
Snapshots come in many types: storage, filesystem, database, application, backup, index, full, incremental, differential, crash-consistent, and application-consistent.
The important question is not only what type of snapshot exists, but what it can restore.
For production vector databases, use the right snapshot type for the job and prove it through restore testing.