VirtualBox: How to Use Snapshots
Based on Corey Schafer's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Create an initial snapshot immediately after a fresh VM install and power-down to guarantee an easy recovery point.
Briefing
VirtualBox snapshots let administrators save a virtual machine’s exact state—settings, disk contents, and optionally memory—so they can roll back experiments quickly without reinstalling an operating system. The practical payoff is speed and safety: network tweaks, software installs, and configuration changes can be tested, then undone by restoring a prior snapshot.
The workflow starts by selecting a virtual machine and opening the Snapshots tab. From there, a “take snapshot” action prompts for a name and description, and the tutorial recommends creating an initial snapshot right after a fresh install and power-down. That baseline becomes the easiest recovery point when something goes wrong later, avoiding a full reinstall and reconfiguration.
Snapshots also form a tree. After taking an initial snapshot, the tutorial demonstrates installing VirtualBox Guest Additions on a powered-off machine, creating a second snapshot, then branching into different software setups. One branch installs Apache by checking service status, installing via apt, and verifying with another status check; a snapshot is taken after Apache is installed. The tutorial then restores back to the Guest Additions snapshot (before Apache) and instead installs Nginx (engine X), again verifying the service and taking a snapshot afterward. The result is one virtual machine with multiple diverging “branches,” where switching between Apache and Nginx setups becomes a matter of restoring the corresponding snapshot.
A key safety detail appears when restoring snapshots while the VM is in a “changed” state. If the machine has uncommitted changes and an earlier snapshot is restored, VirtualBox warns that the current state may be lost unless a new snapshot of the change state is created first. The tutorial shows both behaviors: sometimes creating a new snapshot to preserve the current state, and other times unchecking that option when the goal is to discard the current changes.
VirtualBox snapshots can also capture runtime memory state when taken while the VM is running. The tutorial highlights the tradeoff: memory snapshots can consume significant disk space because the machine’s RAM contents are saved to a file. To illustrate, it creates a “working” snapshot while the VM is running with an unsaved document open, then powers down without saving and restores the snapshot. After restoration, the open document and in-progress work reappear, confirming that the running state was preserved.
Under the hood, VirtualBox snapshot contents include a complete copy of VM settings (hardware configuration), a full rollback of virtual disk state (files created after the snapshot disappear, deleted files return, and modified files revert), and—when applicable—the memory state for running machines. The tutorial’s overall message is pragmatic: snapshots are best used for configuration and software testing with the VM powered off, while running snapshots are reserved for cases where preserving live work is worth the extra storage cost.
Cornell Notes
VirtualBox snapshots provide a rollback mechanism for virtual machines by saving VM settings, virtual disk state, and—if taken while running—memory state. Creating an initial snapshot after a fresh install makes it easy to recover from mistakes without reinstalling the operating system. Snapshots form a tree, enabling branching test paths from the same baseline—for example, one branch can install Apache while another installs Nginx after restoring to the same earlier snapshot. Restoring while the VM is in a “changed” state triggers a warning and can require creating a snapshot of the current state to avoid losing changes. Running snapshots preserve in-progress work but can consume substantial disk space due to saved RAM contents.
Why create an “initial install” snapshot right after setting up a VM?
How do snapshot “branches” help when testing different software stacks?
What happens if the VM has unsaved changes and an earlier snapshot is restored?
What exactly gets saved in a snapshot when the VM is powered off?
Why are snapshots taken while the VM is running treated differently?
How can you tell whether a snapshot was taken while the VM was offline or running?
Review Questions
- When would you prefer restoring a snapshot over reinstalling a guest OS from scratch, and what initial snapshot strategy supports that?
- Describe how snapshot branching enables testing both Apache and Nginx setups using a single VM.
- What storage risk comes with taking snapshots while a VM is running, and what benefit does that runtime snapshot provide?
Key Points
- 1
Create an initial snapshot immediately after a fresh VM install and power-down to guarantee an easy recovery point.
- 2
Use the Snapshots tab to take, restore, delete, and inspect snapshot details; name snapshots clearly with matching descriptions.
- 3
Snapshots form a tree, allowing branching test paths from the same baseline state (e.g., Apache on one branch, Nginx on another).
- 4
Restore operations during a “changed” state can trigger a warning; decide whether to preserve the current state by creating an additional snapshot.
- 5
Snapshot contents include VM settings and virtual disk state; restoring reverts disk changes so created files vanish and modified files revert.
- 6
Taking snapshots while the VM is running can preserve memory and in-progress work, but it can consume significant disk space due to saved RAM contents.