DejaVaultby Tessaro Systems
Configuration backup and restore for Cisco Meraki
DejaVault records every change across your clients' Meraki organizations, keeps the full configuration behind each one, and restores a network from a plan you approve before anything is written.
In development. Early access starts with backups and change history on a read-only API key.
| Time | Admin | Client / network | Setting |
|---|---|---|---|
| 4:42 PM | d.reyes@harbor-it.example | Coquina Bay DentalCBD-TPA-14 Westshore | Port forwarding Inbound port open to any |
| 3:10 PM | m.okafor@harbor-it.example | Ridgeline Cold StorageRCS-LAK-03 Warehouse | SSID "RF-Scanners"Pre-shared key changed |
| 2:55 PM | API: ops@harbor-it.example | Northmoor Academy40 networks | Switch port schedules One change, 40 networks |
| 11:03 AM | s.lindqvist@harbor-it.example | Coquina Bay DentalOrganization | Dashboard administrators New full admin |
| Description | Protocol | Public port | LAN IP | Local port | Allowed remote IPs | |
|---|---|---|---|---|---|---|
| − | Imaging RDP | TCP | 3389 | 10.14.20.31 | 3389 | 203.0.113.0/24 |
| + | Imaging RDP | TCP | 3389 | 10.14.20.31 | 3389 | Any |
Change log read every minute
Changes reach your timeline within about a minute of Meraki logging them.
A year of history on day one
DejaVault imports each org's last 365 days of change log when you connect.
Read-only for backups
Write access exists only for a restore you approve.
MX, MS and MR first
Undo, restore and rebuild start with appliances, switches and access points.
What the Meraki change log can't do
The dashboard's change log records old and new values as text. Nothing turns that text back into a working firewall, VLAN or SSID, a long rule list arrives as a single block, and entries stop at about 4,096 characters.
L3 firewall rules
A 42-rule list edited by hand
The log shows the before and after as two blocks of text. Finding the rule that changed, and typing the old list back in, is manual work.
DejaVault shows the change rule by rule and puts the previous list back with one approved restore.
Deleted network
A network removed by mistake
Its VLANs, firewall rules, SSIDs and port settings go with it, and its devices return to inventory unclaimed.
DejaVault rebuilds the network from its last snapshot, re-claims its devices and rebinds its template.
Inherited organization
An org taken over from another MSP
No documentation, no record of who changed what, and administrators or API keys that may still work.
DejaVault imports a year of change history and lists every dashboard administrator and API key it finds.
Backups that report their own gaps
DejaVault snapshots the settings a change touched as soon as it appears in the change log, and runs a full backup of every org overnight. Each configuration section is recorded as backed up, not applicable or failed, so a partial backup is never shown as complete.
- A failed section marks the snapshot partial and alerts youAt launch
- At most half of Meraki's per-org API rate, leaving room for your own toolsAt launch
- Manual snapshots, and an automatic one before every restoreAt launch
- Meraki's regional clouds, each org on its own API addressAt launch
| Appliance › L3 firewall rules | 42 rules | Backed up |
| Appliance › Port forwarding | 9 rules | Backed up |
| Appliance › VLANs | 6 VLANs | Backed up |
| Appliance › Site-to-site VPN | spoke, 2 hubs | Backed up |
| Wireless › SSIDs | 15 SSIDs (4 enabled) | Backed up |
| Switch › Ports | 48 ports (1 switch) | Backed up |
| Cellular gateway › Uplink | no device | Not applicable |
| Appliance › Content filtering | HTTP 502, 3 retries | Failed |
One change timeline across every client
Every change, newest first: who made it, when, and which client, network and setting, with the full old and new values from DejaVault's own snapshots. Firewall rules, NAT, VLANs, SSIDs and switch ports are shown as the tables you know from the dashboard, with rules matched by identity rather than by line.
- Filters for client, network, admin, setting and dateAt launch
- One admin's change to forty networks shown as one rowAt launch
- Compare any two snapshots, or a network with its live configurationAt launch
- Alerts as tickets in ConnectWise, Autotask and HaloPSA, and in Teams or SlackLater
Risky-change alerts, on by default
Your own rulesBy setting, by admin or by network, including "everyone except these admins". Preview 30 days of what a rule would have caught before you switch it on.
Every alert links to an undoRisky changes email at once. Other rules send one daily digest per person, or alert instantly if you prefer.
Undo a setting, restore a network, rebuild what was deleted
Undo one change straight from the timeline, restore a network from any snapshot, or rebuild a network that no longer exists. You see every API call before it runs, and every restore can itself be reversed through the same steps.
- Restore every section, or only the ones you chooseAt launch
- Rebuilds re-claim devices from inventory and remap new IDsAt launch
- Settings owned by a template are listed and left aloneAt launch
- Restore a configuration template as its own jobLater
- Copy a network into another org, for takeovers and org splitsLater
- PUTnetworks/{id}/appliance/firewall/l3FirewallRulesRewrites all 42 rules; 3 differ
- PUTnetworks/{id}/appliance/vlans/20DHCP options for VLAN 20 "Imaging"
- BATCHdevices/Q2HP-••••-••••/switch/ports24 ports, 2 batches
- PUTnetworks/{id}/wireless/ssids/2Needs the RADIUS secret for "Staff"; used once, not stored
- SKIPnetworks/{id}/appliance/trafficShapingOwned by template "Clinic standard"
Evidence for auditors, clients and your own records
Reports show what was backed up, what changed and who changed it. Your data stays yours: the full backup can be exported at any time, and a copy can land in your own storage every night.
| Report or export | What it shows | When |
|---|---|---|
| Backup healthper org | Last good backup, failed sections, API keys about to stop working | At launch |
| Coverageper network | The share of settings captured, and which connection captured them | At launch |
| Monthly proof reportPDF per client | Snapshots taken, changes made and restores run, in your branding or ours | At launch |
| Firewall and NAT exportCSV or PDF | Rules across all of a client's networks, for auditors | At launch |
| Full backupJSON | Everything, for Admins with a fresh authenticator code | At launch |
| Nightly copyAmazon S3 or SFTP | Your backups in storage you control | At launch |
| Takeover assessmentread-only | A free review of a prospect's estate before you take it over | At launch |
What happens when you run a restore
Undoing one setting, restoring a network and rebuilding a deleted one all follow the same steps, in this order. Nothing is written until you have approved the plan, and nothing outside the plan is written at all.
- Plan
- Read the live configuration, compare it with the snapshot, and list only the calls needed for the differences.
- Preview
- A readable before and after for each section, with the exact API calls.
- Secrets
- Ask for values Meraki never returns, such as RADIUS secrets. Used once, never stored.
- Confirm
- Type the network's name and enter a fresh authenticator code.
- Safety snapshot
- Capture the network exactly as it is before anything changes.
- Execute
- Write in dependency order with retries. A failure pauses the job and shows the error.
- Verify
- Snapshot again and compare with the source. Anything left over is listed.
- Reverse if needed
- The safety snapshot can be restored through these same steps.
Every write is checked against the approved job. Its org, its networks and its planned calls are fixed when you confirm, down to each action inside a batch. Anything else is refused and logged.
What a restore can bring back, and what it can't
Meraki's API does not return everything it stores, and some things cannot be recreated through it. We list the gaps up front, and every restore plan shows them before you approve it.
Restored from the backup
- Network settingsVLANs, firewall and NAT rules, port forwarding, site-to-site VPN, SSIDs, group policies, switch ports and alerts, for MX, MS and MR at launch.
- Organization objectsPolicy objects and groups, restored before the networks that use them.
- Deleted networksRecreated with new IDs mapped in every later call, devices re-claimed from inventory and the template rebound.
Needs you, or waits on Meraki
- RADIUS secrets and MX Wi-Fi passwordsMeraki never returns them, so you enter them during the restore. They are used once and not stored.
- Pre-shared keysMasked to a read-only key. Enter them at restore time, or choose a full-access backup key to capture them.
- Settings a template ownsLeft alone by a network restore. Template restore is its own job, in a later release.
- Device claimsMeraki allows 10 claim calls per 5 minutes from one address, so large rebuilds claim devices in paced batches.
- Cameras, sensors, cellular gateways, Systems ManagerBacked up at launch; restore follows in a later release.
Questions to ask any Meraki backup vendor
Most tools can take a copy of a configuration. These are the questions that separate a copy from a recovery plan.
| Ask this | DejaVault's answer |
|---|---|
| Does the backup need write access to my orgs? | No. Backups use a read-only key. Write access is granted per restore and expires when the job ends. |
| Will it tell me when a backup is incomplete? | Yes. Every section is recorded as backed up, not applicable or failed, and a partial snapshot raises an alert. |
| Can I see exactly what a restore will write before it runs? | Yes. The live value, the value to be written and the exact API calls, section by section. |
| Can it rebuild a network that was deleted? | Yes. It recreates the network, re-claims its devices from inventory, rebinds its template and restores every section. |
| Can I reverse a restore? | Yes. A safety snapshot is taken before the first write and can be restored the same way. |
| Does it show who made each change? | Yes. The admin on every change, or the owner of the API key and the endpoint, on one timeline across all clients. |
| What does it do with configuration templates? | Settings owned by a template are listed and left alone, so restoring one site never changes the others. |
| Will it tell me what it can't restore? | Yes. Secrets Meraki never returns, settings a template owns and anything else outside the restore are listed in the plan before you approve it. |
| Can I take my data with me? | Yes. A full JSON export at any time, and a nightly copy in your own Amazon S3 bucket or SFTP server. |
Designed for people who hold the keys to client networks
Backups hold a read-only key. Restores borrow a write key for one job, and it expires when the job ends.
Read-only backups
A read-only API key from a dedicated service admin, or Meraki OAuth with read-only permissions.
Write keys per restore
Held under a restore-only encryption key. You can choose to store one, under the same protection.
A key per customer
Each customer's backups and secrets are encrypted under their own key. Deleting a customer destroys it.
Locked backups
Snapshots cannot be changed or deleted for 30 days, and are copied to a second region.
Our own audit trail
Every sign-in, restore, export, key and role change, with the person's name, also kept in locked storage.
A code for every restore
Restores and full exports need a fresh authenticator code, so a stolen session cannot run either.
No staff restores
Our team can support and bill your account. It cannot run a restore in your org.
Fixed outbound addresses
If your orgs limit API access by IP address, you add ours and nothing else changes.
Tested before launch
An outside penetration test before general availability, and a monthly restore drill in our lab org with the results published.
Hosted on AWS in the United States. EU hosting is planned for EU customers. Report a security issue: security.txt.
For MSPs and in-house network teams
The same service works for a managed service provider with many client organizations and for an IT team running its own Meraki estate.
Managed service providers
Clients, their organizations and their networks are kept apart inside one account, with one timeline across all of them.
- Monthly proof reports per client, in your brandingAt launch
- Read-only assessments of estates you are bidding forAt launch
- Two roles: Viewer for history and reports, Admin for restores, keys and usersAt launch
- Logins for your clientsLater
Enterprise IT teams
One organization or many, with the change history an audit asks for and a way back that does not depend on a vendor ticket.
- A year of changes with old and new valuesAt launch
- Sign-in with an emailed code or Microsoft, authenticator for restoresAt launch
- SAML single sign-onOn request
- A second approver for restoresOn request
- Customer-held encryption keys or a dedicated deploymentOn request
Early access
We are starting with a small number of MSPs and IT teams. Early access begins with one organization on a read-only key: backups, coverage and change history. Tell us how many organizations and networks you run, and which PSA you use.
What you get
- Backups and history on your own orgs, read-only
- Direct contact with the people building it
- Early-access pricing
What we ask
- A read-only API key for one or more orgs
- A short call every few weeks
- Your list of what breaks most often
Questions from MSPs
Do you need write access to our Meraki organizations?
No. Backups use a read-only API key. A restore asks for a write-capable key for that job only, and it expires when the job ends. If you prefer, you can store a restore key under the same restore-only protection.
What does a backup cover?
Every configuration endpoint in Meraki's published API, with any exceptions listed on a coverage page at launch. Undo, restore and rebuild cover security appliances (MX), switches (MS) and access points (MR) first; cameras, sensors, cellular gateways and Systems Manager follow.
What happens with configuration templates?
A network restore puts back the network's own settings and local overrides. Settings owned by a template are listed in the plan and left alone, so restoring one clinic never changes the template shared by the others. Restoring a template is a separate job, planned for a later release.
Can we connect with Meraki OAuth instead of an API key?
Yes, for backups with read-only permissions. Some settings and every bulk action batch have no OAuth permission, so an API key covers those and restores. The coverage report shows which connection captured each setting.
What about pre-shared keys and RADIUS secrets?
A read-only key sees some of them masked, and Meraki never returns RADIUS secrets. By default you enter them during a restore; they are used once and not stored. You can choose a full-access backup key to capture pre-shared keys.
How long is history kept, and where?
A year of history by default, on AWS in the United States, encrypted under a key that belongs to your account. Snapshots are locked for 30 days and copied to a second region. You can export everything at any time.
How will pricing work?
Pricing is not final. Our plan is a price per network, pooled across all of your clients rather than charged per organization, so an MSP with many small clients is not penalized. Early-access customers get early-access terms.
Is Tessaro Systems affiliated with Cisco?
No. Tessaro Systems is an independent company, and DejaVault uses Meraki's published APIs.
Connect one org and see its history
DejaVault early access starts with a single organization and a read-only key. Nothing in your network changes.