Cisco Meraki has no undo button. Here is how to give it one.

Ask a room of network engineers what happens when someone fat-fingers a firewall rule across two hundred Meraki networks, and you tend to get the same answer: you find out the hard way.

Cisco Meraki earned its reputation by making cloud-managed networking feel effortless. Provision a device, and the dashboard pushes the right settings down automatically. That convenience hides a quiet assumption, though: that the current state in the cloud is the same thing as a safety net. It is not.

The dashboard is not a backup

Meraki configuration lives in the cloud, and when a device fails the dashboard re-pushes its settings to the replacement. Genuinely useful, but it solves a different problem.^[1] There is no native configuration-backup feature in the dashboard and no one-click rollback to a previous state.^[3]

So when someone changes a firewall rule, misconfigures a VLAN, or pushes a bad SSID policy across every network at once, there is no built-in way to see exactly what changed, compare it against what you had before, or revert it. The cloud faithfully serves the broken configuration, because as far as it knows, that is now the configuration.

The Change Log only gets you so far

The closest native option is to work backwards through the Change Log under Organization, undoing edits by hand.^[2] For a single small change on a quiet network, that works. At scale, across hundreds of networks and dozens of admins, reconstructing what happened from the Change Log becomes a forensic exercise, and it does not cover every configuration element consistently.^[1]

What real recovery looks like

The consensus among engineers who have lived through a bad change is to pull the full configuration by API and keep it yourself.^[2] A credible setup has four properties:

• Full coverage. Organization, network, and device settings, not just the headline ones. The value of a backup is the part you forgot you depended on.
• Versioned history. Timestamped snapshots you can return to, captured on a schedule or whenever a change is detected, so you can recover a specific point in time rather than just the latest.
• Comparison. The ability to diff any two snapshots and see exactly what changed. This is what turns troubleshooting from guesswork into evidence.^[1]
• A tested restore. Whatever method you choose, verify you can actually restore from it before you have to do it under pressure.

Why compliance teams care too

If your organization operates under PCI DSS, HIPAA, SOC 2, NIST, or ISO 27001, you typically have to demonstrate that network configuration changes are tracked, documented, and reversible.^[1] A cloud that simply re-serves the current state cannot show any of that on its own. An external, versioned, audit-logged backup can.

Closing the gap

None of this is a criticism of Meraki as a platform. It is a reminder that disaster recovery is a separate job from device management, and the dashboard was built for the latter. The fix is not exotic: capture the full config regularly, keep the history, make it diffable, encrypt it, and rehearse the restore. Do that, and a bad change at 4 p.m. on a Friday becomes an undo instead of an outage.