A snapshot is a point-in-time image of a storage volume, file system or virtual disk that records its exact state at one instant and allows the data to be read or rolled back to that state later. In servers, within backup and recovery, snapshots provide very fast capture and very fast restore, because they are created inside the storage layer and usually copy no data at the moment they are taken.
Snapshots are a building block of protection, not a complete backup strategy. Because a snapshot normally lives on the same storage as the original data, it protects against deletion, corruption and failed updates, but not against the loss of the disk array, the host or the site.
How a snapshot captures data without copying it
A snapshot freezes the block map or metadata that describes where the data lives, not the data itself. From that moment, the storage system must keep the original blocks intact for the snapshot while allowing the live volume to change. Two main techniques achieve this: copy-on-write and redirect-on-write.
With copy-on-write, the first time a block changes after the snapshot, the old content is copied to a reserved area before the new content overwrites it. Each first write therefore costs an extra read and write. With redirect-on-write, new data is written to a fresh location and the live map is updated, so the old block simply stays where it was. Copy-on-write file systems such as ZFS and Btrfs follow this second approach, which makes snapshots nearly free to create.
| Technique | How changes are handled | Main trade-off |
|---|---|---|
| Copy-on-write | Old block copied aside before overwrite | Extra write load after each snapshot |
| Redirect-on-write | New data written to a new location | Fragmentation over time |
| Split-mirror clone | Full mirror detached at a point in time | Needs full capacity, independent copy |
| Log-based | Changes tracked in a journal | Restore requires replaying the log |
In every technique, the space a snapshot consumes grows with change, not with volume size. A snapshot of a 2 TB volume where 20 GB changed afterwards occupies roughly those 20 GB plus metadata.
Consistency levels of a snapshot
A snapshot taken without coordination is crash-consistent: it looks exactly like the disk after a sudden power loss. Journaling file systems and most databases can recover from that state, but data still held in memory or in application buffers is not included, and recovery may require log replay or repair.
For dependable restores, the snapshot is coordinated with the software above it. The file system is frozen briefly, the database flushes its buffers or enters a backup mode, and only then is the snapshot taken. The resulting application-consistent snapshot can be restored without recovery steps.
| Consistency level | How it is achieved | Suitable for |
|---|---|---|
| Crash-consistent | Snapshot taken with no coordination | Stateless servers, file shares |
| File-system-consistent | File system frozen during capture | General servers, logs, documents |
| Application-consistent | Application flushes and pauses writes | Databases, mail and transactional systems |
Volumes that belong together, such as a database’s data and log volumes, must be captured in one consistency group. Separate snapshots taken a few seconds apart can produce a combination that never existed and cannot be opened.
Snapshots compared with backups
The central rule of backup and recovery is that a snapshot is not a backup until it is copied somewhere independent. Snapshots share the physical media, the controller and often the administrative credentials of the original, so a single failure or a single attacker can destroy both.
| Property | Snapshot | Full, incremental or differential backup |
|---|---|---|
| Creation time | Seconds, nearly independent of size | Minutes to hours, depends on data volume |
| Restore time | Seconds for a rollback | Minutes to hours for a copy back |
| Storage location | Same system as the source | Separate media or site |
| Protection from hardware loss | None on its own | Yes, if stored elsewhere |
| Typical retention | Hours to a few weeks | Weeks to years |
In practice the two are combined. A backup tool takes a snapshot to obtain a stable source, reads it at leisure, and sends a full or incremental backup to separate storage. Changed-block tracking between successive snapshots makes these incremental backups efficient, because only modified blocks are transferred.
Using snapshots well
Snapshots are most valuable for short-term, frequent recovery points. A schedule of hourly snapshots kept for a day and daily snapshots kept for two weeks gives many rollback options at low cost, while longer retention belongs to the backup system.
| Use case | Recommended practice | Reason |
|---|---|---|
| Before an upgrade | Manual snapshot, delete after success | Instant rollback if the update fails |
| Ransomware resilience | Immutable snapshots with separate admin rights | Attacker cannot delete recovery points |
| Source for backups | Application-consistent snapshot, then copy off | Stable data without long downtime |
| Test environments | Clone a snapshot as a writable copy | Realistic data in seconds |
- Limit the number of snapshots per volume, because long snapshot chains slow writes and complicate merges.
- Monitor snapshot reserve usage; a full reserve can invalidate snapshots or stop writes.
- Include snapshot rollbacks in every restoration test, not only full restores.
Limitations and common mistakes
The most damaging mistake is treating snapshots as the only copy. A failed array, a deleted storage pool or compromised credentials removes the data and all its snapshots at once. A second mistake is keeping virtual machine snapshots for weeks: the growing delta files degrade performance and make the final consolidation slow and risky.
Rolling back is also coarse. Reverting a whole volume discards every change made after the snapshot, including legitimate ones, so for small losses it is often better to mount the snapshot read-only and copy back only the affected files.
In plain words
A snapshot is like taking a photo of a whiteboard before someone starts erasing and rewriting it. If the new writing turns out wrong, the board can be put back exactly as it was in the photo, almost instantly.
The catch is that the photo is kept in the same room as the whiteboard. If the room burns down, both are gone. That is why snapshots are excellent for quick undo, but a real backup must still be stored somewhere else.
A real-world example
A hosting team runs a customer database of about 800 GB on a server with a ZFS storage pool. Every hour, a script asks the database to flush its buffers and takes an application-consistent snapshot; hourly snapshots are kept for 48 hours and daily ones for 14 days. Each night, the newest daily snapshot is sent incrementally to a backup server in another building.
One afternoon, a faulty migration script deletes a column in several tables. Instead of restoring 800 GB from the backup server, which would take hours, the team clones the snapshot from 40 minutes earlier, verifies the data and switches the application over. Service is restored in about 10 minutes, and only the last 40 minutes of changes need to be reconciled from application logs.