Skip to content
SZ-MCP
Get Support

Switch config backup and restore

Claude can list, read, take and restore ICX switch configuration backups held by SmartZone’s SwitchM. Reading is open to every role. Taking a backup is an ordinary write you confirm. A restore is a dry run until you say otherwise, needs a backup of the switch from the last 15 minutes, and is a dangerous action. A restore changes only the switch’s startup config, so it takes effect at the switch’s next reboot.

FunctionWhat it doesKind
switches.backups({ switchId, limit })Per switch, newest first: the newest successful backup and its age, the master backup, whether the newest differs from the master, failed backups since, the last restore, and up to limit backups (default 5, at most 100)Read
switches.config({ backupId }) or ({ switchId })One backup as text, or a switch’s newest successful backup. Secrets show as <secret>. match keeps only the sections containing a phrase, such as snmp-serverRead
switches.backup({ switchIds, master })Takes a backup of 1 to 50 switches now. master: true also makes it the switch’s master, the reference SwitchM compares later backups withWrite
switches.restore({ backupId, apply, freshMinutes, force })Restores a backup to its switch. A dry run unless apply: trueDangerous write

switchId is the switch’s MAC address. If a switch has no successful backup, switches.config answers “No successful backup of switch; switches.backup takes one.”

1 to 5 minutes, nearly all of it queued. switches.backup returns as soon as SwitchM accepts the request, with the hint Backups take 1 to 5 minutes (queued, then run): check switches.backups({ switchId }) for the new one. Ask Claude to check switches.backups after a few minutes.

It writes the backup to the switch’s startup config, which applies at the next reboot. The running config does not change. Until the switch reboots, nothing you see on it changes.

  1. Dry run. Ask Claude to restore a backup. Without apply, nothing is sent: you get the backup, the switch’s newest successful backup, whether that one is fresh, and a diff of what the restore changes relative to it, with secrets masked.
  2. Fresh backup. With apply: true, the restore is refused unless the switch has a successful backup from the last 15 minutes (freshMinutes, 1 to 1,440), so there is a copy to go back to. Claude takes one with switches.backup and waits for it.
  3. Approval. The restore goes through the write guard. Under the default policy it is a dangerous action, so you confirm it and also give your authenticator code or approve it on the dashboard.
  4. Queued. SwitchM queues the restore. switches.backups({ switchId }) shows the last restore going PENDING, then STARTED, then SUCCESS, about 5 to 7 minutes later.
  5. Reboot. Reboot the switch from SmartZone or the switch itself, only after the restore shows SUCCESS. A reboot while it is still pending boots the old config.

To go back, restore the fresh backup you took before, the same way.

Restore refusedMessage
No such backup”No backup id.”
The backup did not succeed”Backup id has status status; only a successful backup can be restored.”
No fresh backupfresh_backup_required: “The newest successful backup of switch is older than 15 minutes. Take one with switches.backup(…), wait until switches.backups shows it, then restore again. force: true skips this only if the user says so.”

Because the default write policy ticks “Restore a controller or switch configuration backup”. A dangerous action needs your authenticator code, or a dashboard approval if you have none. If an admin unticks that category, a restore becomes an ordinary write that you confirm in chat. See Approving dangerous changes.

A restore cannot be reversed with history.undo: it is an action, not an update. Going back means restoring another backup.