A virtual machine snapshot captures the exact state of a virtual machine at a single moment, its disk contents and often its memory too, so that you can return to that moment later. For anyone maintaining a SCADA or HMI server that runs as a virtual machine, this is one of the most useful safety nets available: take a snapshot before a risky patch or configuration change, and if it goes wrong, roll straight back to how things were. But a snapshot is not a backup, and treating it as one is a common and dangerous mistake. This guide explains what a snapshot really is, how it differs from a backup, and how to use both correctly.
VM Snapshot in one line: A VM snapshot is a point-in-time capture of a virtual machine's disk state, and optionally its memory, that lets you roll the machine back to exactly how it was when the snapshot was taken. It is ideal for reverting a bad patch or configuration change quickly. It is not a backup, because it lives on the same storage as the VM and depends on the original disk, so it does not protect against storage failure or provide long-term recovery.
When you take a snapshot, the virtualization platform freezes the virtual machine's current disk as a read-only reference and begins writing all subsequent changes to a separate delta file. From that moment, the original disk stays untouched and every new write goes into the delta. If you decide to revert, the platform discards the delta and returns to the preserved original disk, putting the machine back exactly as it was. If you keep the changes, the delta is eventually merged back into the base disk. A snapshot can also capture the running memory, so reverting can restore not just the files but the live running state of the machine.
This mechanism is what makes a snapshot such a fast, low-effort safety net. Taking one is nearly instantaneous because nothing is actually copied up front; the platform simply redirects new writes. That low cost is exactly why it fits so naturally before a risky operation. The value is not in long-term storage but in giving you a clean, immediate escape hatch for a change you are about to make and might need to undo within minutes or hours.
The classic use is patching. Before applying an operating system update, a vendor patch, or a configuration change to a production HMI or SCADA server, an administrator takes a snapshot. If the patch breaks the application, corrupts a driver, or introduces some subtle misbehaviour, reverting the snapshot returns the server to its known-good state in moments, without reinstalling anything. That ability to undo turns a nerve-wracking change on a live production system into something reversible, which is why snapshots are a standard part of careful change management for virtualized industrial systems.
The single most important thing to understand is that a snapshot is not a backup. A snapshot lives on the same storage as the virtual machine and depends on the machine's original disk to function; the delta file only makes sense in relation to the base disk it branched from. If the underlying storage fails, the disk is corrupted, or the datastore is lost, the snapshot goes down with it, because it was never a separate, independent copy of the data. A real backup, by contrast, is a self-contained copy stored on separate media or a separate system, able to restore the machine even if the original storage is completely gone.
The two also serve different time horizons and purposes. A snapshot is for short-term reversibility around a specific change, measured in minutes to a few days. A backup is for genuine data protection and disaster recovery, kept for weeks, months, or years, and designed to survive the loss of the primary system. Confusing the two leads people to believe they are protected when they are not: a stack of snapshots gives you rollback but no defence against storage failure, ransomware that reaches the datastore, or a lost site.
There is also a performance and integrity trap in leaving snapshots around long-term. As a snapshot's delta file grows with ongoing writes, it consumes storage and can degrade the virtual machine's disk performance, and long chains of snapshots become fragile and slow to consolidate. This is why the guidance is to use snapshots as temporary tools: take one before a change, and either revert or delete it promptly once you have confirmed the change is good. Running a production SCADA or HMI server on top of an old, forgotten snapshot for weeks is asking for both poor performance and eventual trouble.
In control environments, HMI servers, SCADA application servers, and historians are frequently run as virtual machines, precisely so that operators can benefit from snapshots, easy migration between hosts, and simpler hardware refreshes. The snapshot is the tool that makes routine maintenance on these critical machines less risky. Windows updates, control-software upgrades, driver changes, and security patches all carry a chance of breaking a finely-tuned system, and the ability to revert in minutes changes the risk calculation for applying them. This encourages teams to stay current on patches instead of avoiding updates out of fear, which is good for security.
A sensible operational pattern is to snapshot immediately before any planned change, verify that the system and its communications are healthy after the change, and then delete the snapshot once you are confident, rather than leaving it lingering. For the harder job of surviving a real disaster, such as a server that will not boot, corrupted storage, or a lost site, you rely on proper backups kept independently, ideally with copies offsite. Snapshots and backups are complementary: snapshots handle fast rollback of intentional changes, backups handle recovery from loss.
Cloud monitoring changes the picture in a helpful way for the parts of a system that live in the cloud. Where a platform such as Merobix holds the historian and dashboards centrally, the durability of that data is the cloud provider's responsibility, with its own redundancy and backup rather than a single VM you must snapshot and back up by hand. On-site machines that still run control and local HMI remain the operator's to protect, and there the snapshot-before-change discipline, backed by real backups, remains essential. Understanding which data lives where tells you which recovery tool applies to each part of the system.
No, and treating a snapshot as a backup is a common and risky mistake. A snapshot lives on the same storage as the virtual machine and depends on the original disk, so it disappears if that storage fails. A real backup is an independent copy on separate media that can restore the machine even if the original storage is lost. Use snapshots for short-term rollback and backups for genuine data protection.
Take a snapshot immediately before any risky change, such as an operating system update, a control-software upgrade, a driver change, or a security patch. If the change breaks something, you can revert to the known-good state in minutes without reinstalling. After you have verified the system is healthy, delete the snapshot rather than leaving it in place long-term.
As a snapshot's delta file grows with ongoing writes, it consumes storage and can slow the virtual machine's disk performance, and long snapshot chains become fragile and slow to consolidate. Snapshots are meant to be temporary tools for reversing a specific change. Leaving a production machine running on an old snapshot for weeks risks both degraded performance and eventual data problems.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.