ArubaOS-CX Checkpoint and Rollback Configuration

2026年9月19日 LOG admin

Bundling every interface into the wrong VLAN, or pushing an ACL that severs the management path, is the classic way to lock yourself out of a switch. ArubaOS-CX takes the sting out of that scenario with configuration checkpoints: named snapshots of the running configuration that you can diff against, copy back, or use as an automatic safety net. This guide covers creating checkpoints, comparing them, rolling back, and configuring the auto-checkpoint timer that quietly saves you when a change goes wrong at 02:00.

What a checkpoint actually is

A checkpoint is a saved copy of the switch configuration — not the running config on disk, but a separate object with its own name. AOS-CX creates them in two ways:

Manual checkpoints: created by you before a change, for example copy running-config checkpoint before-vlan-change.
Automatic checkpoints: created by the system itself. If you change the configuration and do not save it, the switch creates a checkpoint automatically after a configurable idle period (5 minutes by default) with a timestamped name such as CPC20180709164306.

Creating and listing checkpoints

# Interactive CLI
switch# copy running-config checkpoint before-vlan-change
switch# copy startup-config checkpoint known-good-startup

# Automatic checkpoints, shown with a date/time name
switch# show checkpoint list
NAME                        TYPE      DATE
before-vlan-change          manual    2026-09-19 03:12:44
CPC20260919025831           auto      2026-09-19 02:58:31
known-good-startup          manual    2026-09-18 22:40:09

The auto-checkpoint feature is what makes an unattended change window survivable. Rather than remembering to snapshot, you let the switch snapshot for you and then update the interval:

switch(config)# checkpoint auto 60          # create an auto checkpoint every 60 minutes
switch(config)# checkpoint auto confirm 10 # keep the last 10 auto checkpoints

Comparing before you commit

Never roll back blind. Diff the checkpoint against the running configuration first, then read the output carefully — the symbols are the whole point of the command.

switch# checkpoint diff before-vlan-change running-config

# Symbol guide
#  +   line exists in the running config but not in the checkpoint
#  -   line exists in the checkpoint but not in the running config
#  @   line is present in both but has a different value

If the diff shows the management VLAN or an SSH ACL changing, that is your smoking gun before a rollback rather than after it.

Rolling back

A rollback applies an existing checkpoint over the configuration. Everything configured since that checkpoint is lost, so roll back during a window even when the alternative is being cut off.

# Revert the running configuration to a checkpoint
switch# checkpoint rollback before-vlan-change

# Or copy in the specific direction you need
switch# copy checkpoint before-vlan-change running-config
switch# copy running-config startup-config

Read that last pair of commands as one operation: rolling back the running configuration without saving leaves the switch one reload away from the broken configuration again.

Auto-rollback when the change cuts you off

The most valuable variant for remote work is automatic rollback triggered by loss of connectivity. In UI-managed groups, AOS-CX can detect that the switch stopped reaching its management platform after a configuration push and revert to the last known stable configuration on its own. Aruba Central documents roughly a 10 minute window for the switch to complete the rollback and reconnect, and the event is recorded in the Audit Trail with the auto-commit state set back to Off so no further push is applied until a human reviews the diff.

That behaviour is the reason to push risky changes through the management platform rather than typing them at the CLI:

Platform push + auto-rollback = the switch restores itself if the change breaks reachability.
CLI change = you had better have a manual checkpoint and an out-of-band path.

Operational habits worth adopting

Take a manual checkpoint with a meaningful name immediately before every change — copy running-config checkpoint pre-change-<ticket>.
Leave auto-checkpoints enabled with an interval that matches your change frequency (30–60 minutes is typical).
Run checkpoint diff as part of the verification step, not just as a troubleshooting step.
Save the configuration after a successful change so the checkpoint list reflects the intended state, and prune old checkpoints during housekeeping.

Done this way, "restore the switch to how it was an hour ago" becomes a one-line command instead of a console cable and a prayer.