Menu
|
Menu
If you manage fewer than 20 Meraki networks, your config backup strategy is probably “I know what’s configured because I configured it.” And that works. Until it doesn’t.
Somewhere between 50 and 100 networks, the mental model breaks. You can’t remember every VLAN assignment, every firewall rule, every SSID configuration across every site. When something changes unexpectedly, you’re left comparing dashboard screenshots or scrolling through the change log hoping to spot what moved.
After 1,100+ customer deployments across enterprise Meraki environments, here’s what we’ve learned about config backup strategies that actually hold up at scale.
Let’s address this directly: the Meraki dashboard is not a config backup system. It’s a management plane.
The dashboard shows you the current state of your network. It has a change log that records who changed what and when. But it doesn’t do several things that matter for operational resilience:
It doesn’t capture full config snapshots. The change log tells you a VLAN was modified. It doesn’t preserve the complete configuration state from before the change, making it difficult to compare current state against a known-good baseline.
It doesn’t retain historical config states long-term. If you need to know what your firewall rules looked like six months ago, across 200 networks, the dashboard isn’t designed to answer that question.
It doesn’t alert you to compliance drift. You can see changes after they happen, but there’s no mechanism to define “this is what the config should look like” and get notified when reality diverges from the standard.
It doesn’t support cross-org comparison. If you manage multiple Meraki organizations, which most enterprise customers do, there’s no native way to compare configurations across orgs or enforce consistency.
None of this is a criticism of Meraki. The dashboard is excellent at what it’s designed for: cloud-managed network operations. Config lifecycle management is a different discipline, and it requires different tooling.
Based on patterns we see across environments ranging from 50 networks to 5,000+, effective config backup strategies share five characteristics.
Manual backups fail for a simple reason: people forget. Or they’re busy. Or they run the backup after the change, which means you’ve captured the new state, not the one you might need to roll back to.
Best practice: Automate config capture so it runs continuously, triggered by change detection rather than a schedule. In our deployments, we poll the Meraki API every 60 seconds. When a change is detected, a full config snapshot is captured automatically.
The key distinction is change-triggered vs. scheduled. A nightly backup misses everything that happened between 8 AM and midnight. Change-triggered capture ensures you have a snapshot of the state before every modification.
What this looks like at scale: For an environment with 2,000 network entities, change-triggered backups generate roughly 50-200 snapshots per day, depending on how active the environment is. Storage is cheap. Missed changes are expensive.
A backup you can’t find is a backup that doesn’t exist. Enterprise environments need config history measured in months, not days.
Best practice: Retain config snapshots for at least 365 days, with the ability to search and compare across any two points in time.
Why 365 days? Three reasons:
What to avoid: Backup systems that only retain the last N snapshots per device. This works for small environments but creates blind spots at scale. You want time-based retention, not count-based.
Backing up configs is necessary but not sufficient. You also need to know when a config deviates from what it should be.
Best practice: Define compliance baselines for critical configuration elements and monitor for drift continuously.
Common baseline rules we see in enterprise deployments:
When any of these drift, the team should know immediately, not at the next quarterly review.
The compliance-to-snapshot link: Every compliance alert should reference the specific config snapshot that triggered it. This creates an auditable trail: “At 2:47 PM on March 15, the config for Network X violated Rule Y. Here’s the exact config state.”
Networks get decommissioned. Devices get removed. Orgs get restructured. What happens to the config data when the entity it belongs to no longer exists?
Best practice: Implement a retention buffer for orphaned entities. Don’t delete config history the moment a device or network is removed.
We typically recommend a 14-day retention window for orphaned entities. This handles the most common scenarios:
After the retention window, orphaned data can be archived or purged based on your data governance policy.
The edge case nobody plans for: Org mergers and acquisitions. When two Meraki orgs get consolidated, device histories from the source org need to survive the transition. If your backup system is org-scoped, you lose history during consolidation.
The ultimate test of a config backup strategy is whether you can actually use it to recover. A backup that exists but can’t be restored is a checkbox, not a capability.
Best practice: Test restore procedures quarterly. Document the recovery workflow. Know the answer to these questions before you need them:
A note on encrypted fields: Some configuration elements, like RADIUS shared secrets, are encrypted in the Meraki API and can’t be exported in plaintext. Your restore procedure needs to account for manually re-entering these values. This is a Meraki API limitation, not a tooling limitation, and any backup approach needs to document which fields require manual re-entry after restore.
After 1,100+ deployments, certain patterns repeat:
“We export to CSV monthly.” CSV exports capture a point-in-time snapshot of selected parameters. They don’t capture the full config, they’re not searchable, and they go stale immediately. It’s better than nothing, but it’s not a backup strategy.
“Our MSP handles backups.” Confirm what this actually means. Some MSPs back up the Meraki org-level config. Some back up device-level settings. Some do neither and are relying on the dashboard’s change log. Ask for specifics.
“We use the Meraki API to pull configs into Git.” This approach has merit for version control, but it requires significant engineering to maintain at scale. API rate limits, pagination handling, error recovery, and schema changes all need to be managed. For a team with dedicated DevOps resources, it works. For a network team that also has a day job, it’s a side project that will eventually be deprioritized.
“We’ll deal with it when something breaks.” The cost of rebuilding a network config from scratch, including the troubleshooting time, the user impact, and the incident response overhead, almost always exceeds the cost of automated backups by an order of magnitude.
Run this quick assessment against your environment:
If you answered “no” to two or more of these, your environment has outgrown your current approach.
Config backup at scale isn’t a project. It’s an operational discipline. The right approach depends on your environment’s size, your compliance requirements, and your team’s capacity.
For Meraki environments under 50 networks, manual processes can work with discipline. Between 50 and 200, you need automation. Above 200, you need a purpose-built platform.
Boundless Safeguard was built for the 200+ tier. It’s available on the Cisco Networking App Marketplace and on Cisco’s General Price List through Cisco Commerce Workspace.
Noel-Edouard Chenu is the CEO of Boundless, a Cisco ecosystem software company specializing in network lifecycle management. Boundless has completed 1,100+ customer deployments across enterprise Meraki environments.
1207 Delaware Ave #552, Wilmington, Delaware 19806
Americas: +1 (347) 464 6510 - EMEA: +33 (0) 181 22 12 80
