checkpoint [name]
Creates a named checkpoint of the current running configuration that can be used to roll back to a known state.
Definition: checkpoint [name] is a Cisco NX-OS exec command. 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.
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 | Description |
|---|---|---|
| name | WORD | 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-changeCheckpoint 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-20250315Checkpoint 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) --- ServersSteps
- 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'.
! 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.
checkpoint [name] vs copy running-config startup-config
Both checkpoint and copy running-config startup-config are used to preserve the running configuration, but they serve different purposes. Checkpointing creates a volatile snapshot in memory for quick rollback, while saving to startup-config ensures persistence across reloads. This distinction is often confused by engineers who may assume a checkpoint is automatically permanent.
| Aspect | checkpoint [name] | copy running-config startup-config |
|---|---|---|
| Scope | Creates named snapshot of running-config in memory | Copies running-config to startup-config file |
| Persistence | Volatile; lost on reload unless explicitly saved | Persistent; survives reload |
| Restoration method | Rollback to checkpoint via rollback command | Used automatically as boot configuration |
| Overwrite behavior | Does not overwrite existing checkpoints; adds new one | Overwrites previous startup-config |
| Number of copies | Multiple named checkpoints possible | Only one startup-config |
Use checkpoint [name] when you are about to make risky configuration changes and want a quick way to revert without affecting the saved startup configuration.
Use copy running-config startup-config when you want to make the current configuration permanent so it survives a system reload.
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 CCNP Data Center
Test your knowledge with practice questions covering all CCNP Data Center exam domains.
Practice CCNP Data Center Questions