Cisco Meraki disaster recovery: backing up your network configuration

How Meraki stores your configuration

In a Meraki network, the Meraki dashboard is the source of truth. When an administrator changes a setting, the change is saved in the Meraki cloud and pushed to the device. Meraki's cloud architecture documentation explains how that data is protected:

• Configuration is held as a container for each device in the Meraki back end, updated with every change.
• It is replicated in real time between independent data centres in the same region. Each region has at least two geographically separate data centres, and organisations in Meraki's Europe region are hosted in Germany.
• Nightly archival backups are also kept with in-region third-party cloud storage services, as a further layer if both data centres were affected.
• Dashboard and API services are replicated across data centres so they can fail over.
• Your traffic is not in the cloud. Meraki's architecture is out of band: the cloud holds management data (configuration, statistics and monitoring), while user traffic flows directly across your LAN and WAN.

The hosting region is chosen when the organisation is created, and Meraki advises a separate organisation for each region you operate in.

What disaster recovery means for a Meraki network

Because Meraki protects the cloud side, a Meraki disaster recovery plan concentrates on the things you control. It helps to separate five risks:

No single product makes a Meraki network recoverable. A good plan:

• Holds a copy of the configuration you control, taken regularly and stored outside the Meraki organisation.
• Records who changed what, so a bad change can be found and reversed quickly.
• Removes single points of failure at the sites that matter most: appliances, circuits and power.
• Has replacement steps written down and tested, including who can claim a replacement device.
• Keeps admin access resilient, so no single person or phone is the only way in.
• Covers video, if you run MV cameras, with MV Cloud Archive for footage that must survive a camera being lost.

On the first risk, Meraki's documentation says a device that loses cloud connectivity continues to run with its last known configuration and keeps trying to reconnect, then picks up any newer configuration when it does. Meraki also describes a "safe configuration": the last configuration a device received that was not followed by a reboot within 30 minutes. Meraki documents that an MX that loses its cloud connection while running a newer configuration that is not yet safe can, depending on its firmware, revert to the last safe one.

How to back up Meraki network configurations

Meraki's documentation explains that the dashboard configuration is held as a container in its back end, protected by the replication and backups above, rather than exported as a local file. To keep an independent copy as well, the Meraki API is the tool:

1. Create a read-only administrator for the backup job, with its own API key, so the job cannot change anything.
2. Read the settings that matter: organisation administrators and policies, networks, templates and bindings, VLANs, SSIDs, firewall and traffic shaping rules, site-to-site VPN settings, switch ports and device details.
3. Save each run as dated files in storage you control, outside the Meraki organisation.
4. Schedule it, daily or after planned change windows, and keep enough history to go back before a mistake was made.
5. Compare runs, so a backup also shows what changed between two dates.
6. Test a restore of one network into a test network, so you know the copy is complete.

Alongside the API copy, keep the design records an engineer would need to rebuild a site: addressing plans, circuit details, port maps and licence information. We can help set up the backup job, choose what it should capture and write the restore steps.

Recovering from a mistake: change log, templates and cloning

Most real-world Meraki recoveries are not disasters but mistakes: a firewall rule removed, a VLAN changed on the wrong network. The dashboard has several tools for this:

• The change log (Organization > Monitor > Change log) records every configuration change across the organisation with the time, the administrator, the network, the page, the setting changed, and its old value and new value. Meraki keeps the last 12 months of history for organisations in the EU. To undo a change, find it and set the old value back.
• Configuration templates hold the standard design for groups of sites. If a bound network drifts through local overrides, the template remains the reference, and a template-bound replacement network inherits everything in one step.
• Network cloning. When creating a network you can clone the configuration of an existing one, which is a quick way to rebuild a site or stand up a replacement.
• Configuration Sync (Organization > Configuration Sync) copies chosen settings, such as SSIDs or MX traffic shaping and threat protection settings, from one MX or MR network to another. It does not work with combined or template-bound networks.

Firmware is another common source of surprises. Schedule upgrades for each network in quiet hours and try new versions on a small network first.

Hardware failure: warm spare MX and replacements

The security appliance is the single point of failure at most sites, and Meraki offers two ways to handle its failure:

• Warm spare (high availability). Two MX appliances of the same model run as an active and standby pair, using VRRP to detect failure, so the spare takes over automatically. Meraki needs only one licence for the pair. The two units must be the same model and regional variant. Meraki's swap button changes the roles but is not a failover test; to test, disconnect the primary's uplink in a maintenance window.
• Cold swap. Without a spare, a replacement MX is added to the network and installed in place of the failed one. Meraki documents two methods: a quick swap in the same network, or cloning the network, staging the replacement in the clone and then swapping. Both are faster if the steps are written down before they are needed.

For other devices, a replacement access point added to the same network picks up that network's wireless settings. For a replacement switch, Meraki's guidance is to clone the failed switch's configuration onto the new one in the dashboard, or follow the stacking guide for a stack member. Meraki's installation guides explain that once support confirms a device has failed, an RMA replacement is processed; keeping one spare of your most common models on the shelf can shorten the wait at critical sites.

Do not forget the circuit: a second internet line, or 4G or 5G through a Meraki MG cellular gateway, keeps a site connected when the main line fails. Our Meraki SD-WAN guide explains failover between links.

Consolidating Meraki dashboard organisations

Mergers, acquisitions and early design decisions often leave a business with several Meraki organisations that would be easier to run as one. Meraki dashboard consolidation is now much simpler than it was, because of network portability:

• What it does. Network move lets you move a network from one organisation to another while keeping its configuration and devices together, so it does not need rebuilding. It works with appliance, camera, switch, wireless and combined networks.
• How to run it. Through the Cisco Managed Automation Workflow in the dashboard or the Network Move API. A simulate option runs the validation checks without moving anything.
• Before you start. Both organisations must be on the same regional dashboard, the network must not be a template or bound to one, and site-to-site VPN and SSID tunnelling must be turned off for the move. For moves through the API, the user needs write access in the source organisation and organisation write-admin access in the destination.
• Timing. Meraki says most moves complete in under 20 minutes, and the move is recorded in both organisations' change logs.
• Licensing. Not every combination of licensing models can move: subscription-to-co-term moves, for example, are not supported. Check the licensing rules first.

Where a network cannot be moved this way, the manual route is to remove devices from the old organisation and claim them into the new one. Meraki notes that the device's configuration does not migrate on that route (so build the receiving network first), that a removed device can take up to 60 minutes before it can be claimed again, and that removing a camera from a network deletes its footage. Licences can only move between organisations belonging to the same customer.

Meraki dashboard migration checklist

1. Inventory both sides: networks, devices, licences and their expiry dates, administrators, templates, integrations and API keys in use.
2. Choose the destination design: one organisation per hosting region, a naming scheme, templates and administrator roles.
3. Check licensing: the licensing model of each organisation, whether licences can move, and how the co-term date or subscriptions will look afterwards.
4. Take a configuration copy of every network through the API before anything moves.
5. Find the dependencies: Auto VPN between sites, MX appliances acting as concentrators for wireless networks, SSID tunnelling, and organisation-wide policies that will need recreating.
6. Simulate first: run network moves in simulate mode and fix any blocking settings.
7. Plan the windows: move a pilot site, then the rest in planned maintenance windows, with VPN reconfigured as each site arrives.
8. Check afterwards: device status, VPN status, alerts, administrators and integrations in the destination organisation, and the change logs on both sides.
9. Tidy up: remove old administrator accounts and API keys, and update documentation and any CMDB feed.

The same checklist applies when a Meraki dashboard migration moves networks for another reason, such as splitting one organisation into two, or separating a business that has been sold.

How Forever Systems helps

Forever Systems is a Cisco Partner. For Meraki resilience and migration we can review your organisation for single points of failure, set up an API-based configuration backup, add warm spare appliances and cellular backup at critical sites, and plan and run organisation consolidation or dashboard migration projects. The scope is agreed at quote.

For resilient hardware, shop the Meraki firewall range and the cellular gateways, add what you need to your basket and request a quote. To review your disaster recovery plan, contact us.