Ever built a flawless lab setup in GNS3 only to break everything with a single misstep, like a wrong BGP config or a misapplied ACL? That’s where snapshots and rollback come in.
Table of contents:
A GNS3 lab snapshot is like pressing pause on your entire topology. It freezes the exact state of every node, link, interface, and even the disk. Rollback lets you jump back to that saved state later, like a time machine for your lab. Together, they form your safety net, letting you test boldly, fail safely, and recover instantly.
This is way different from just hitting "Save As" in GNS3. "Save As" only saves your topology file, which is the blueprint of your lab. Snapshots capture everything: running configs, virtual machine disk states, RAM content, and the entire network runtime.
Labs are for experimenting and breaking things. But what happens when you break things a little too well? Whether you're typing out a complex prefix-list for BGP, manually licensing a virtual firewall, or testing tricky route redistribution, you’re always just one bad command away from wrecking your whole setup.
Before snapshots, your options were grim: either rebuild the entire lab or spend hours unpicking your changes. Now, you just revert the GNS3 project to the last known good state, and you're back in business.
Snapshots make your lab work:
Under the hood, GNS3 snapshots capture the state of a whole working system. Here’s how it all works:
This all gets tucked away in the .gns3/snapshots/ folder inside your project directory. Each snapshot gets its own timestamped folder with the VM disk images and related data. In a hosted environment like CloudMyLab, this storage is all managed for you automatically.
Each GNS3 snapshot is timestamped and can be given a short description (e.g., “Before firewall NAT config”). You’ll see these versions in the GNS3 GUI timeline, making it easy to track lab changes over time.
Need to save lab state before a big experiment? Just name the snapshot accordingly and take the risk without worry.
Hit "Rollback" in GNS3, choose your snapshot, and you’re back to that exact point in time.
Rollback restores everything: startup configs, running configs, interface statuses, routing tables, and sometimes even the CLI history. This works seamlessly whether you're running GNS3 locally, on the GNS3 VM, or even in a multi-host cloud environment.
Working with a team? In multi-user setups or team labs, rollback works across all nodes and users simultaneously. When you restore a snapshot, your entire class or team gets restored to the same known state.
GNS3 snapshots are usually reliable, but knowing the warning signs of potential problems can save you from losing hours of valuable lab work.
Here’s how to handle the most common GNS3 snapshot problems.
If a snapshot won't restore, first check if the file itself looks right. Go to your .gns3/snapshots/ folder and look for files that are suspiciously small. If your 8-router lab snapshot is only 500KB, something's wrong. Delete it and hope you have an older, good backup.
If the snapshot files look okay but still won't restore, GNS3's metadata might be messed up, but the actual VM disks could be fine. In that case, you can play "VM disk detective": grab the .vmdk or .qcow2 files from the snapshot folder, copy them to your main project directory, and manually re-import your nodes in GNS3.
Nothing quite prepares you for the moment when you restore a snapshot and discover your carefully orchestrated topology has been scattered across multiple servers like confetti at a wedding.
If you restore a snapshot and find your carefully arranged topology has been scattered across multiple compute servers, it can happen in multi-server setups (or when using the GNS3 VM with remote computes) if GNS3 loses track of which server was hosting which nodes.
The fix is simple, though a bit tedious: Stop everything (a full stop, not just a pause), then manually reassign each node back to its correct compute server by right-clicking it and changing the compute assignment. Before taking snapshots in multi-server setups, it's a good idea to take a screenshot of your compute assignments.
If GNS3 freezes while creating a snapshot, it's usually your system choking on too many running VMs or not enough disk space.
Memory issues are the sneaky killers. Your lab might run fine, but when GNS3 tries to snapshot everything at once, it chokes. The quick fix? Close Netflix, Spotify, and those 47 Chrome tabs you have open. The real fix? Either upgrade your RAM or accept that your 20-node CCIE lab might be a bit ambitious for your laptop.
Storage problems are even more frustrating because they often fail silently. You think you've got a good snapshot, but it's actually corrupted because your disk ran out of space halfway through. Keep at least 20% of your drive free, and regularly clean out old snapshots that are hogging space like digital pack rats.
The dreaded "snapshot timeout" usually means your storage is too slow for the snapshot size. If you're still using a spinning hard drive for GNS3, this is your wake-up call to join the SSD revolution.
Sometimes, snapshots just break. Keep multiple snapshots and regularly export your device configs as a separate backup. First, check if the files are actually there. If they are but won't load, GNS3's snapshot index file might be corrupted. You can try deleting the snapshots.json file and letting GNS3 try to rebuild it, but this isn't guaranteed to work.
Let’s walk through a simple scenario with Cisco IOSv routers to show how snapshots work.
Lab Topology: R1 --- R2 --- R3
On all routers:
hostname R1 # R2/R3 respectively
interface Gig0/0
ip address 10.0.12.1 255.255.255.0 # R1/R2: 10.0.12.2; R2/R3: 10.0.23.2 & .3
no shutdown
Take Snapshot: Save this as "base-config" before adding any routing protocols.
On all routers:
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
(Ping across all routers to verify reachability).
Take Snapshot: Save this as "ospf-configured" with full OSPF adjacencies working.
Remove OSPF and add EIGRP:
no router ospf 1
router eigrp 10
network 10.0.0.0 0.0.0.255
Take Snapshot: Save this as "eigrp-configured" with EIGRP fully operational.
Now, if you want to compare how the protocols behave or if something breaks during your EIGRP experiment, you can easily roll back to the stable ospf-configured state in seconds, or even go back to the base-config state to start a whole new experiment (maybe with IS-IS).
At CloudMyLab, we’ve enhanced snapshots for professional engineers and students.
Our hosted GNS3 snapshot engine offers:
GNS3 snapshots and rollback are powerful tools for any network lab. They let you experiment without being afraid of making irreversible mistakes, saving you a ton of time and making your learning experience better. By following best practices for creating and managing snapshots, you can build a reliable safety net for your GNS3 projects. For an even more robust and hassle-free experience, consider a hosted solution like CloudMyLab, where advanced snapshot management is built-in. This lets you focus on what's important: building your networking skills.
Destroy your lab fear-free - Launch your test lab now
With CloudMyLab, yes. Our REST API lets you create pre-change and post-change snapshots via automation tools like Terraform, Ansible, or Jenkins.
In the GNS3 GUI, go to the "Snapshots" pane, type in a name for your snapshot, and click the "Create snapshot" button.