SystemEXEC

checkpoint [name]

Creates a named checkpoint of the current running configuration that can be used to roll back to a known state.

Overview

The 'checkpoint' command in Cisco NX-OS (Nexus) creates a named snapshot of the current running configuration. This snapshot, or checkpoint, can be used later with the 'rollback' command to revert the device's configuration to the exact state captured at the time the checkpoint was created. This is a critical tool for configuration management, especially in production environments where changes must be carefully controlled. The concept behind checkpoints is similar to version control: you save a known good state before making modifications, so you can quickly undo changes if they cause problems. On Cisco NX-OS, checkpoints are stored in the device's memory and can be viewed with 'show checkpoint'. They are not automatically saved to the startup configuration; to persist across reloads, you must explicitly save the checkpoint using 'copy running-config startup-config' or the checkpoint will be lost upon reboot. Checkpoints are particularly useful during maintenance windows, software upgrades, or when implementing complex configuration changes. They fit into troubleshooting workflows as a safety net: before troubleshooting a configuration issue, create a checkpoint to ensure you can always return to the original state. Unlike the 'archive' feature in Cisco IOS, NX-OS checkpoints are simpler and more direct, focusing on manual snapshots rather than automatic periodic saves.

Syntax·EXEC

checkpoint [name]

When to Use This Command

Before applying a major configuration change, create a checkpoint to allow quick rollback if the change causes issues.
During maintenance windows, create checkpoints at each step to enable incremental rollback.
After verifying a stable configuration, create a checkpoint as a baseline for future comparisons.
When testing new features, create a checkpoint before enabling them to easily revert if problems occur.

Parameters

Parameter	Syntax	Required	Description
name	WORD	Required	A user-defined name for the checkpoint. It can be any alphanumeric string, including hyphens and underscores. The name must be unique; if a checkpoint with the same name exists, it will be overwritten.

Command Examples

Create a checkpoint before a VLAN change

checkpoint pre-vlan-change

Checkpoint pre-vlan-change created successfully.

The checkpoint named 'pre-vlan-change' is saved. It can be used later with the 'rollback' command to restore the configuration to this point.

Create a checkpoint with a timestamp name

checkpoint config-20250315

Checkpoint config-20250315 created successfully.

Using a date-based naming convention helps organize checkpoints. The output confirms the checkpoint was saved.

Understanding the Output

The output of the 'checkpoint' command is minimal: it simply confirms that the checkpoint was created successfully. If the checkpoint name already exists, the command will overwrite it without warning. There is no detailed output to parse; the key information is the success message. If the command fails (e.g., due to insufficient memory or a locked configuration), an error message will appear. A healthy response is the exact confirmation line. No problem values exist beyond failure messages.

Configuration Scenarios

Pre-change checkpoint for OSPF configuration

A network engineer needs to modify OSPF parameters on a Nexus switch in the data center core.

Topology

Nexus-7000 (core) --- Nexus-9000 (agg) --- Servers

Steps

1.Create a checkpoint named 'pre-ospf-change'.
2.Apply the OSPF configuration changes.
3.If issues arise, rollback using 'rollback checkpoint pre-ospf-change'.

Configuration

! On Nexus-7000
checkpoint pre-ospf-change

Verify: Use 'show checkpoint pre-ospf-change' to verify the checkpoint exists and view its content.

Watch out: If you forget to create the checkpoint before changes, you cannot rollback to the previous state unless you have a backup.

Troubleshooting with This Command

When troubleshooting configuration issues on Cisco NX-OS, the 'checkpoint' command is a proactive tool rather than a reactive one. The best practice is to create a checkpoint before any troubleshooting session that involves configuration changes. For example, if you suspect a routing issue and plan to modify OSPF timers, first create a checkpoint. If the changes worsen the problem, you can immediately rollback. To use checkpoints in troubleshooting, first list existing checkpoints with 'show checkpoint'. If you have a checkpoint from a known good state, you can compare it to the current running configuration using 'show checkpoint [name] diff running-config'. This shows the differences and helps identify what changed. If the issue is recent and you have a checkpoint from before the change, you can rollback entirely. However, checkpoints are not a substitute for backups; they are temporary snapshots. For long-term configuration history, use the 'archive' feature or external version control. On NX-OS, checkpoints are stored in the 'system:checkpoints' directory and can be exported via TFTP or SCP for off-device storage. If a checkpoint becomes corrupted or the device runs out of memory, the 'checkpoint' command may fail. In such cases, delete unnecessary checkpoints with 'no checkpoint [name]' to free space.

CCNA Exam Tips

Remember that checkpoints are stored in the 'show checkpoint' output and can be deleted with 'no checkpoint [name]'.

Checkpoints are not saved across reloads unless you use 'copy running-config startup-config' after creating them.

The 'rollback' command uses checkpoints; know the syntax 'rollback checkpoint [name]'.

Common Mistakes

Forgetting to create a checkpoint before making changes, leaving no easy rollback path.

Using the same checkpoint name repeatedly, overwriting previous checkpoints without realizing it.

Assuming checkpoints persist after a reload without saving them to startup-config.

Platform Notes

On Cisco NX-OS, the 'checkpoint' command is similar to the 'archive' command on Cisco IOS, but simpler. IOS uses 'archive config' to create incremental backups, while NX-OS uses named checkpoints. There is no automatic checkpointing in NX-OS; it must be done manually. On Cisco IOS, you can use 'archive config' with a path to save configurations to a server, but NX-OS checkpoints are stored locally. The equivalent on IOS would be 'copy running-config flash:checkpoint-name' but without the rollback integration. On NX-OS, the 'rollback' command is tightly coupled with checkpoints. In NX-OS versions prior to 6.x, checkpoints were not available; they were introduced later. Also, on Nexus 9000 series running NX-OS, the behavior is identical. Note that checkpoints do not include non-configuration state like dynamic routing tables or interface counters; they only capture the running configuration. For a full system state, consider using 'system checkpoint' (different command) for ISSU purposes.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions