Virtual-machine snapshots
A known checkpoint helps restore a lab, with limits.
The idea
A snapshot records a virtual machine’s state at a chosen point so it can be reverted. Behavior depends on the hypervisor and whether memory or storage state is included. Snapshots are useful before lab changes, but they are not a complete independent backup. Reverting can remove newly collected work or evidence, so export needed records first. Label snapshots with purpose and verify restoration when setting up the lab.
In practice
A learner snapshots a clean vulnerable target before an exercise, stores findings outside the VM, and reverts afterward for the next task.
A common misunderstanding
A snapshot stored with the same underlying files may be lost if the host storage fails.
Check your understanding
What should happen before reverting after a useful exercise?
Think it through: Save the report, screenshots, logs, and any other evidence needed for later learning.
A snapshot is a point in a dependency chain
A fictional learner takes a snapshot before changing a training server. Reverting later can restore the captured state according to the hypervisor's design, but the snapshot may depend on underlying virtual disks and host storage. It should not be treated as an independent backup surviving loss of those files.
Decide whether the snapshot includes memory and what that means for the exercise. Restoring a running-state capture can resume processes and connections under conditions that have changed outside the VM. A disk-only baseline may have different behavior. Use the product's documented semantics rather than assuming every snapshot is equivalent.
External state does not necessarily revert. A report saved on a shared folder, a remote API call, or a record in another VM may remain changed. Restoring one guest therefore does not automatically restore an entire distributed lab to a consistent point.
Label a baseline with its purpose
For a local exercise, record the snapshot name, date, VM configuration, application state, and intended next task. Create a harmless file after the snapshot, save needed notes outside the guest, and verify what remains after restoration. Do not test restoration on a machine holding irreplaceable work.
Keep the number and lifetime of snapshots manageable under hypervisor guidance. Long chains can complicate storage and maintenance. Before a revert, export evidence and confirm which changes will be lost. A useful snapshot workflow makes the starting state reproducible while keeping learning artifacts durable. It supports experimentation, but recovery from host loss still requires an appropriate backup strategy beyond the snapshot itself.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
Kali Linux documentationOracle VirtualBox: First Steps and Snapshots