Snapshot

A snapshot is a point-in-time representation of a specified computing data set or system state, not necessarily an independent physical copy. Its contents represent capture time, not the present. A volume is a storage area: its capture covers stored data, a database capture covers database state, and a virtual-machine (VM) capture covers the state supported by that system.

Captured data, configuration settings and runtime memory vary by implementation. A checkpoint captures VM state for later return. Hyper-V standard checkpoints include memory; production checkpoints capture data-consistent state without memory, so restoring the latter does not resume the captured runtime session.

How Earlier State Is Preserved

Storage is divided into units called blocks. With copy-on-write, the system saves a block's original contents before allowing a later write to overwrite it. Saved originals and still-required source blocks together expose the earlier view, without an initial full duplicate.

Redirect-on-write sends later writes elsewhere, leaving original blocks intact. As an alternative, a shadow-copy provider can make a complete, read-only volume copy at the selected time.

Incremental capture records changes since an earlier capture; it is not another name for copy-on-write. For Amazon EBS, the first snapshot is full: it includes every data block written to the volume at capture. Subsequent snapshots save only blocks changed since the most recent snapshot, avoiding duplication of unchanged data. Later recovery points reference previously stored blocks as well as newly stored changes, so restoration can recover the captured volume contents rather than just the newest changes. Deleting an earlier recovery point removes data used exclusively by it, while data referenced by other recovery points is preserved.

Reduced copying can shorten capture and save storage, but maintenance costs depend on workload. SQL Server snapshots represent fixed contents while their files grow as the live database changes; space exhaustion makes them unusable. Efficient capture does not guarantee instant capture or restoration.

Testing and Recovery

Hypothetical VM example: Assume a separate test VM supporting checkpoint creation and reversion. Capture its working configuration at 10:00; apply an update at 10:15. If the update causes trouble and required checkpoint and source state remain available, revert to 10:00. The VM resumes its runtime session only if the chosen checkpoint type captured memory. Taking a snapshot neither creates test isolation nor reverses external effects on other systems.

In a separate database testing environment, supported reversion to the same captured starting data between runs supports repeatable tests.

Regularly retained suitable recovery points can limit damage from accidental deletion or erroneous changes. Reversion can discard post-capture work; a newer suitable point can reduce that loss interval. Frequency and retention depend on recovery needs. SQL Server reversion can be faster than backup restoration, but requires an online, uncorrupted source and cannot subsequently roll forward to reapply later updates.

Recovery Copies and Migration

For migration preparation, Hyper-V export bundles a checkpoint as a VM for movement; import restores it as a VM. EBS can create a new data volume from a recovery point. A pre-change recovery point also provides fallback only while reversion is supported and required state remains available. Neither process alone guarantees transfer of every system component, migration correctness or destination compatibility.

Hypothetical cloud-volume example: Capture an EBS volume at 09:00, edit it at 10:00, and accidentally delete data at 11:00. A replacement volume created from the 09:00 recovery point contains the 09:00 data, excluding later edits. This restores volume data, not automatically an entire configured, running system. Restoration time depends on implementation and storage resources.

Capture Consistency

Consistency concerns whether captured data forms a coherent, recoverable state. Coordinated capture can complete pending transactions and flush cached writes to disk. With supported, cooperating components, applications may remain online, although writes can pause temporarily.

A disk-only, crash-consistent capture preserves data already on disk, potentially omitting cached or unflushed writes and requiring application verification or recovery. Memory inclusion is a separate property: a local VM checkpoint does not automatically ensure consistency across replicated systems.

Relationship to Backups

An independent backup remains recoverable without the lost original data or its required original storage. A snapshot may or may not provide that independence.

• Source dependence. Some recovery points still require original blocks, databases or storage; storing differences on another volume does not make them independent. SQL Server database snapshots become unavailable with their source and do not protect against disk errors or corruption.
• Copying strategy. Full and incremental backups can complement these recovery points, and some captures serve as backups themselves. EBS, for example, stores its incremental recovery points separately and replicates their data across Availability Zones within the region.
• Backup completion. Other workflows transfer captured data or changed blocks to isolated backup storage. Capture alone does not mean that transfer has finished.

Disaster recovery and reduced downtime require an appropriate protection design and a tested restore plan, not merely a successful capture.