Menu
|
Menu
If you manage Cisco Meraki networks, here is something that might surprise you: there is no native GUI backup feature in the Meraki Dashboard.
Your configurations live in the cloud, and Meraki will re-push them to replacement hardware. But that is not the same as a backup. If someone changes a firewall rule, misconfigures a VLAN, or pushes a bad SSID policy across 200 networks, there is no built-in way to see exactly what changed, compare it to what you had before, or roll it back with a click.
This guide covers everything you need to know about Meraki configuration backup: why the cloud model alone is not enough, the methods available to you today, and how enterprise teams are building real config protection into their network operations.
The most common objection we hear from network teams is: “Meraki stores everything in the cloud, so why do I need a backup?”
Here is why that reasoning breaks down at scale.
When a Meraki device fails, you replace it in the same dashboard network and it inherits the existing config. That works well for hardware failures. But hardware failure is not the most common cause of network outages.
According to Gartner, human error accounts for roughly 80% of unplanned network downtime. A mistyped IP address, an incorrect VLAN assignment, or a botched access policy pushed across multiple sites can take down entire network segments. In these scenarios, the configuration in the cloud is the problem, not the solution.
Meraki provides a Change Log (Organization > Change Log) that records who changed what and when. This is useful for simple auditing, but it has significant limitations for enterprise teams:
If your organization operates under PCI DSS, HIPAA, SOC 2, NIST, or ISO 27001, you likely need to demonstrate that network configuration changes are tracked, documented, and reversible. Meraki’s native Change Log may not meet the audit trail requirements of these frameworks, particularly around:
There are four approaches to Meraki configuration backup, ranging from manual scripts to fully automated platforms. Each has trade-offs around coverage, reliability, and the effort required to maintain it.
You can manually export certain settings from the Meraki Dashboard, such as SSID configurations and client lists. However, there is no “Export Full Configuration” button. This method is:
Best for: Small networks with infrequent changes where basic documentation is sufficient.
The Meraki Dashboard API provides REST endpoints that allow you to read (and write) configuration programmatically. Several open-source scripts exist on GitHub that use these APIs to export configuration as JSON files.
How it works: The Meraki API exposes configuration across dozens of endpoints. A backup script iterates through your organizations, networks, and devices, calling each relevant API endpoint and saving the response as a JSON file. A restore script reverses the process, reading the saved JSON and pushing it back via API PUT/POST calls.
Key considerations for API-based backup:
Best for: Technical teams with Python/API experience who need basic periodic snapshots and are comfortable maintaining custom code.
Several third-party tools offer Meraki configuration backup as a service. These range from simple backup-only tools to comprehensive platforms with change tracking, compliance monitoring, and rollback capabilities.
What to evaluate in a third-party tool:
Best for: Teams that need reliable, automated backup without the maintenance burden of custom scripts.
The most comprehensive approach combines automated backup with real-time change detection, side-by-side comparison, selective rollback, and compliance monitoring in a single platform.
This is the approach Boundless Safeguard takes. Safeguard monitors the Meraki Change Log every 1 to 5 minutes. As soon as a change is detected, it captures a time-stamped snapshot of the affected configuration and stores it for future comparison or restoration. You can perform a full restore (all settings) or a partial restore (specific settings only) with a single click.
What makes this approach different:
Regardless of which method you choose, these practices will help you build a reliable configuration management process.
If your team makes configuration changes daily, a daily backup is the minimum. For organizations with active change windows, consider tools that detect changes in near-real-time rather than relying on scheduled backups.
Rule of thumb: Your maximum data loss window (the time between the last backup and a bad change) should be measured in minutes, not hours.
A backup is only useful if you can restore from it. Schedule quarterly restore tests on a non-production network. Verify that:
Change tracking is not just a compliance requirement. It is the single most useful capability during incident response. When a network is down and you are trying to figure out what happened, being able to answer “who changed what, when, and what did it look like before” is the difference between a 10-minute fix and a 3-hour rebuild.
Establish a “golden configuration” for each network type (branch office, retail location, campus, data center). Use compliance monitoring to detect when networks drift from this baseline, whether from authorized changes that missed a step or unauthorized changes that should not have happened.
Every change window should include:
Enterprise Meraki deployments often span multiple Dashboard organizations (by region, by business unit, by acquisition). Your backup strategy needs to cover all of them from a single pane of glass. A backup tool that only covers one organization at a time creates blind spots and operational overhead.
Different Meraki device types have different configuration surfaces. Here is what you need to back up for each.
MX configuration includes firewall rules (L3 and L7), site-to-site VPN settings, DHCP server configuration, 1:1 and 1:Many NAT rules, traffic shaping rules, content filtering policies, threat protection settings, and SD-WAN/performance class settings.
Why MX backup matters most: A misconfigured firewall rule can expose your network to the internet. A bad VPN change can sever connectivity between sites. MX misconfigurations tend to have the highest business impact.
MS configuration includes port configuration (VLAN assignments, PoE, link aggregation), access policies (802.1X, MAC whitelisting), STP settings, DHCP snooping, QoS policies, and stacking configuration.
Common MS risk: Pushing a VLAN change across all switch ports in a building can take down an entire floor. Selective rollback to specific switch port configurations is critical.
MR configuration includes SSID settings (authentication, encryption, VLAN tagging), RF profiles, bandwidth limits, firewall rules (per-SSID), splash page configurations, and Bluetooth/IoT radio settings.
Common MR risk: Changing an SSID authentication method across a campus can lock out every wireless client simultaneously.
MT sensors, MV cameras, and MG cellular gateways each have their own configuration surfaces. A comprehensive backup strategy should cover all device types deployed in your environment.
Meraki stores your configuration in the cloud and will re-push it to replacement hardware. However, this is not the same as a versioned backup. If someone changes your configuration (intentionally or not), the cloud stores the new version. There is no built-in way to revert to a previous version of your configuration through the Dashboard GUI.
There is no “Export Configuration” button in the Meraki Dashboard for a complete configuration export. You can export certain elements (like client lists and some reports), but a full configuration export requires using the Meraki Dashboard API or a third-party tool.
At minimum, before and after every planned change window. For enterprise environments, we recommend near-real-time change detection that captures configuration snapshots within minutes of any change. This minimizes your data loss window and gives you the most granular rollback options.
Without a backup tool, your options are limited: you can work backwards through the Dashboard Change Log to manually identify and reverse changes, or you can rebuild the configuration from documentation (if it exists). With a backup and rollback tool, you can compare the current configuration to a known-good state and selectively restore the specific settings that caused the issue.
The API covers roughly 75-80% of available configuration settings. Some settings are read-only or not exposed via API. For teams with Python experience, API scripts provide a workable solution for basic backups. For enterprise environments that need full coverage, real-time change detection, comparison, and selective rollback, a purpose-built tool is more reliable and significantly less maintenance overhead.
Yes. Frameworks like PCI DSS (Requirement 1), HIPAA, SOC 2, and NIST require organizations to document and control changes to network configurations. A configuration backup tool with change tracking and audit trail capabilities provides the evidence auditors need: time-stamped snapshots, before-and-after comparisons, and records of who changed what and when.
If you are managing Meraki networks without configuration backup today, here is where to start:
1207 Delaware Ave #552, Wilmington, Delaware 19806
Americas: +1 (347) 464 6510 - EMEA: +33 (0) 181 22 12 80
