Snapshot

What is a snapshot?

A snapshot is a point-in-time capture of the state of a virtual machine, volume or storage system, which lets you quickly return that system to exactly that state later. Snapshots are mainly used in virtualised environments, where a hypervisor records the disk and optionally the memory of a VM. In industry they are a standard tool when changing SCADA servers, Historian databases and engineering stations: if an update fails, the system is back in its previous, working state within minutes.

A snapshot is not a full backup, but a temporary fallback point before a risky action.

🧠 How does a snapshot work technically?

A snapshot does not copy the data. It freezes the existing disk and writes every subsequent change to a separate file. This happens in three steps:

1. Freeze - the hypervisor makes the original virtual disk read-only. Optionally the contents of memory are saved as well, so the VM can be restored including its running programs.
2. Track changes separately - every write after the snapshot moment goes to a delta or differencing file (copy-on-write or redirect-on-write). VMware creates a delta disk per virtual disk for this (-000001.vmdk with a -delta or, on VMFS6, -sesparse data file), Hyper-V uses .avhdx files next to the .vhdx.
3. Revert or merge - on revert, the hypervisor discards the delta and starts the VM from the frozen disk. On delete (consolidation), the changes are written into the base disk instead.

Because the delta file keeps growing for as long as the snapshot exists, a snapshot is small right after creation but can grow considerably after weeks of heavy writes; with a historian or database that writes continuously, this happens fast. In addition, every read has to pass through the whole chain of delta files, which noticeably reduces performance.

🔄 What types of snapshots are there?

Not every snapshot is equally reliable. The difference lies in how consistent the captured data is:

Hyper-V calls snapshots checkpoints and, since Windows 10 and Windows Server 2016, offers two variants: standard (including memory) and production (application-consistent via the Volume Shadow Copy Service or a Linux file-system freeze, without memory). Production is the default; with the ProductionOnly option, Hyper-V does not fall back to a standard checkpoint when the production checkpoint fails. Note that after applying a production checkpoint the VM is powered off and has to boot again. In Proxmox VE, support depends on the storage: ZFS, LVM-thin, Ceph RBD and qcow2 files on file-based storage support snapshots, and since Proxmox VE 9 regular (thick) LVM does too, using a chain of volumes, although that feature is still a technology preview. Creating and deleting internal qcow2 snapshots blocks a running VM and can take minutes to hours on large disks, especially on NFS.

🔍 What is the difference between a snapshot and a backup?

The key difference: a snapshot depends on the original storage, a backup does not. If the base disk or datastore is lost, the snapshot is worthless. VMware therefore states explicitly that snapshots are not backups.

Snapshots do help to achieve a low RPO and RTO for planned changes. Modern backup software also takes a short-lived snapshot itself to write a consistent copy, then removes it again.

🏭 How do you use snapshots in an OT environment?

In OT, more and more systems run virtualised (virtualisation): SCADA servers, HMI clients, historians, licence servers and engineering stations with PLC software. Typical uses are:

• Before patches and updates - a snapshot just before a Windows update or a new version of SCADA or MES software.
• Before configuration changes - to a firewall VM, a historian or a batch control server.
• In test and acceptance environments - returning to a clean baseline between test rounds, for example during a FAT.
• During migrations - a fallback option while moving to a new version or architecture.
• As part of change management and disaster recovery - provided the snapshot is recorded in the change procedure.

Approach for a planned change

1. Register the change and record who creates the snapshot and when it will be removed.
2. Check that a recent, tested backup exists; a snapshot does not replace it.
3. Choose the right type: application-consistent for databases, possibly with memory for an engineering station.
4. Make the change and test the function, including communication with PLCs and clients.
5. Delete or consolidate the snapshot as soon as the change is approved, preferably within 72 hours.

If something goes wrong, recovery means reverting to the snapshot and repeating the functional test before the system goes back into production.

⚠️ What are the practical pitfalls of snapshots?

VMware recommends no more than two to three snapshots per VM (the technical limit is 32 in one chain) and advises against keeping a snapshot for longer than 72 hours. A virtual disk cannot be enlarged while snapshots exist, and you must never cancel a running deletion or consolidation, because that can corrupt data. In OT there are additional, specific risks:

• Historian gaps - reverting a historian loses all process data since the snapshot, unless the collectors buffer data (store and forward).
• Replicated systems - reverting an Active Directory domain controller or a redundant SCADA pair can disrupt replication. Microsoft warns about this for standard checkpoints; since Windows Server 2012, VM-GenerationID protects a domain controller against the worst consequences.
• Time and licences - a reverted VM with memory state has an outdated clock and sometimes invalid licence or certificate data.
• Forgotten snapshots - snapshots created by backup software do not always appear in the management interface and can silently fill up a datastore.

🔐 How do you secure snapshots?

Attackers know that snapshots make recovery possible. MITRE ATT&CK describes deleting them as technique T1490 Inhibit System Recovery: ransomware wipes Windows shadow copies and deletes or encrypts VM snapshots on ESXi hosts. The OT-focused ransomware EKANS also removed shadow copies, and in early 2023 the ESXiArgs campaign encrypted more than 3,800 unpatched ESXi servers worldwide, according to CISA and the FBI. Measures from a security perspective:

• Restrict rights - only administrators may create, revert or delete snapshots (RBAC, least privilege and MFA on hypervisor management).
• Segment management - the hypervisor management interface should not be reachable from office or process networks.
• Log and monitor - record creation, revert and deletion in logging and the change log.
• Protect the contents - snapshots sometimes contain memory with passwords and keys; treat them as confidential data.
• Combine with immutable backups - only an offline or immutable backup survives an attack on the hypervisor itself.

Standards and regulation require this too. IEC 62443-3-3 requires control system backups in SR 7.3 and control system recovery and reconstitution in SR 7.4. NIS2 explicitly lists backup management and disaster recovery as a duty of care, and the Dutch Cyberbeveiligingswet has put that into Dutch law since 15 August 2026. Snapshots contribute to this, but only as a supplement to business continuity with real backups.

❓ Frequently asked questions

Is a snapshot the same as a backup?

No, a snapshot depends on the original virtual disk and storage. If those are lost or encrypted, the snapshot is unusable. A backup is independent of the source and is therefore the real safety net.

How long should you keep a snapshot?

VMware advises keeping a snapshot for no longer than 72 hours and using no more than two to three snapshots per VM. After that, the delta file grows too large and performance suffers. Delete the snapshot as soon as a change has been approved.

What is the difference between a snapshot and a Hyper-V checkpoint?

A checkpoint is the Hyper-V term for a snapshot. Hyper-V offers standard checkpoints, which include memory, and production checkpoints, which are application-consistent via VSS or a Linux file-system freeze. Production checkpoints are the default.

Can you safely revert a SCADA server with a snapshot?

Yes, provided you take into account the data collected since the snapshot and any connected systems. A reverted SCADA server or historian lacks the process data from that period, and redundant or replicated partners can fall out of step. Test the revert in a test environment first.

Do snapshots protect against ransomware?

Hardly, because ransomware deliberately deletes or encrypts snapshots (MITRE ATT&CK T1490). Anyone who takes over the hypervisor also has access to all snapshots. Protection against ransomware requires offline or immutable backups on a separate system.

Does a snapshot also work on a physical server?

On a physical Windows server, the Volume Shadow Copy Service can create shadow copies of volumes, and storage systems or ZFS can take volume snapshots. A full system snapshot including memory, however, is typically a feature of virtualised environments. For physical OT systems, an image backup remains the usual fallback point.

📌 In summary

A snapshot freezes the state of a VM or volume and tracks later changes separately. This lets you roll back within minutes after a failed update or configuration change. In OT environments that is valuable for SCADA servers, historians and engineering stations. Keep snapshots short-lived (72-hour guideline), choose application-consistent variants for databases and secure hypervisor management.

A snapshot is a fast, temporary fallback point before a change, but never a substitute for a separate, tested and preferably immutable backup.