Save Cisco IOS Configurations: copy run start vs write memory
Cisco IOS devices manage their configuration in two primary states: the running configuration and the startup configuration. Understanding the distinction…
Cisco IOS devices manage their configuration in two primary states: the running configuration and the startup configuration. Understanding the distinction between these and the commands used to manipulate them is fundamental for any network professional. This article delves into the mechanics of copy running-config startup-config and write memory, explores their historical context, and outlines best practices for reliable configuration management.
The running configuration resides in the device's RAM, reflecting the current operational state and any immediate changes made by an administrator. The startup configuration is stored in Non-Volatile RAM (NVRAM), serving as the blueprint for the device's configuration upon boot-up. Changes made to the running configuration are volatile; without explicit saving, they will be lost upon a reboot or power cycle.
Understanding the Configuration Files
running-config (RAM)
The running-config is the live configuration currently active on the device. All commands entered in global configuration mode, interface configuration mode, router configuration mode, etc., immediately modify the running-config. It is a volatile configuration stored in dynamic RAM. If the device reboots or loses power, any unsaved changes in running-config are lost, and the device reverts to the startup-config.
Router# show running-config
Building configuration...
Current configuration : 3474 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
...
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
negotiation auto
!
...
end
startup-config (NVRAM)
The startup-config is the configuration stored in NVRAM (Non-Volatile RAM). This configuration is loaded into RAM and becomes the initial running-config when the device boots up. Because NVRAM retains its contents even without power, the startup-config provides persistence for your device's configuration. It's crucial that your startup-config accurately reflects the desired long-term operational state of the device.
Router# show startup-config
Building configuration...
Current configuration : 3474 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
...
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
negotiation auto
!
...
end
Note that in a stable state, show running-config and show startup-config should display identical content. Any discrepancies indicate unsaved changes.
copy running-config startup-config
This command explicitly copies the current configuration from RAM (running-config) to NVRAM (startup-config). This is the modern, preferred, and most explicit way to save your changes in Cisco IOS. When executed, the device prompts for confirmation, specifying the destination filename (which is typically just "startup-config" on most devices).
Router# copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Router#
The [OK] confirmation indicates a successful write operation. This command clearly communicates its intent: to make the currently active configuration persistent across reboots.
write memory (wr)
The write memory command, often abbreviated as wr, serves the same purpose as copy running-config startup-config: it saves the running configuration to NVRAM. This command is a legacy command, originating from older IOS versions, and it acts as an alias for copy running-config startup-config on most modern Cisco IOS and IOS XE devices (versions 12.0 and later, and all IOS XE). While it functions identically, copy running-config startup-config is generally favored for its explicit nature.
Router# write memory
Building configuration...
[OK]
Router#
You can verify that write memory is an alias by using the show aliases command (if available) or by observing the output of show history after executing both commands; they often show up as the longer form.
Key Differences and Best Practices
Functionally, there is no difference between copy running-config startup-config and write memory on contemporary Cisco IOS/IOS XE devices. Both commands perform the same action of copying the running-config to startup-config. The choice often comes down to personal preference or company policy.
However, best practices dictate a robust approach to configuration management:
- Regular Saving: Always execute a save command (
copy run startorwr) after making a series of verified changes to prevent accidental loss due to power outages or reboots. - Verification: After saving, use
show startup-configto confirm that the changes are present in the NVRAM. Compare it withshow running-configto ensure no discrepancies. For critical changes, areload in Xcommand followed by awrite memorycan be a safety net: if the reload fails to bring the device online, it reverts to the previous configuration. Remember to cancel the reload withreload cancelonce confident. - External Backups: Relying solely on NVRAM is insufficient for disaster recovery. Implement a routine to back up configurations to an external server (TFTP, SCP, FTP). This provides an off-device copy in case of hardware failure or accidental erasure of NVRAM.
Router# copy running-config tftp://192.168.10.10/router-config-20231027.txt Address or name of remote host [192.168.10.10]? Destination filename [router-config-20231027.txt]? !!! 3474 bytes copied in 0.320 secs (10856 bytes/sec) Router#For secure backups, SCP is preferred:
Router# copy running-config scp://user@192.168.10.10/path/to/backup/router-config.txt Address or name of remote host [192.168.10.10]? Destination filename [router-config.txt]? Password: router-config.txt 100% 3.4KB 3.4KB/s 00:00 Router# - Configuration Archiving: For devices supporting it (e.g., IOS 12.3T and later), configure configuration archiving. This feature automatically saves dated copies of your running configuration to local flash or a remote server whenever changes are made. This provides a valuable history and rollback capability.
TheRouter(config)# archive Router(config-archive)# path flash:archive/$h Router(config-archive)# write-memory Router(config-archive)# time-period 1440 Router(config-archive)# exit Router# show archive The next archive file will be named flash:archive/Router-1.cfg archive # size checksum name 1 3474 2FF104F5 flash:archive/Router-1.cfg 2 3474 2FF104F5 flash:archive/Router-2.cfgwrite-memorycommand underarchiveautomatically triggers a save to NVRAM when a configuration change is detected, enhancing consistency. - Change Management: Couple saving configurations with a robust change management process. Document all changes, get approvals, and schedule maintenance windows.
Memory Types and Persistent Storage
To fully appreciate configuration saving, it's helpful to understand the underlying memory types:
- RAM (Random Access Memory): Volatile memory where the
running-configresides. Lost on power cycle. - NVRAM (Non-Volatile Random Access Memory): Non-volatile memory where the
startup-configis stored. Retains data without power. Typical size: 32KB to 256KB for configuration. - Flash Memory: Non-volatile memory, larger than NVRAM, used for storing the IOS image, web interfaces, and other system files. It can also store configuration backups (as seen in the
archiveexample).
| Memory Type | Contents | Volatility | Size (Typical) |
|---|---|---|---|
| RAM | Running-config, routing tables, buffers | Volatile | 256MB - 8GB+ |
| NVRAM | Startup-config, configuration register | Non-Volatile | 32KB - 256KB |
| Flash Memory | IOS image, boot helper, configuration backups | Non-Volatile | 64MB - 16GB+ |
Common Pitfalls
- Forgetting to Save: The most common mistake. Hours of configuration work can be lost with a simple reboot if
copy run startis not executed. TheSystem configuration has been modified. Save? [yes/no]:prompt upon exit or reload is a helpful reminder, but it's best not to rely solely on it. - Saving Incorrectly: Accidentally saving a partially configured or broken configuration to
startup-configcan lead to a device booting into an undesirable state. Always verify changes thoroughly before saving. - No Off-Device Backup: Losing a device without an external backup means losing its configuration entirely, leading to significant downtime and manual re-configuration.
- Incorrect TFTP/SCP Server Setup: Issues with file permissions, network connectivity, or server configuration can cause external backups to fail silently or overtly. Always test backup procedures.
- Running Out of NVRAM: While rare for typical configurations, extremely large configurations or excessive logging to NVRAM could theoretically fill it, preventing a successful save. This is more often a concern with older or lower-end devices.