This chapter covers configuration backup and restoration for network devices—a critical skill for maintaining network reliability and security. On the N10-009 exam, this topic appears in Domain 3.0 (Network Operations) and typically accounts for about 5-8% of questions. You will be tested on backup methods (local, remote, TFTP, FTP, SCP), restoration procedures, configuration replace/rollback, and best practices like versioning and verification. Mastering these concepts ensures you can recover from hardware failures, misconfigurations, and security incidents quickly.
Jump to a section
Think of a network device's configuration as a complex blueprint for a high-security building. The blueprint specifies every door's lock type, every window's alarm sensor, every camera's angle, and every guard's patrol path. One day, a fire (hardware failure) destroys the building. Without a copy of the blueprint, the reconstruction would be guesswork—each door might have a different lock, cameras might miss key areas, and guards might walk the wrong routes. Worse, if a disgruntled employee (malicious actor) sneaks in and changes the blueprint, you'd have no way to prove what the original design was.
Configuration backup is like storing a certified copy of that blueprint in a fireproof, off-site vault. When disaster strikes, you retrieve the vault copy, hand it to the reconstruction team (restoration process), and the building is rebuilt exactly as before—same locks, same camera angles, same patrol paths. If someone tampers with the blueprint, you compare the current blueprint against the vault copy to detect changes.
Versioning is like keeping multiple dated blueprint copies in the vault: you can revert to last week's version if this week's changes caused a security flaw. The restoration process must be tested periodically—just as you'd run a fire drill to ensure the blueprint can be read and followed quickly. Without testing, you might find the vault key is missing or the blueprint is water-damaged when you need it most.
What Is Configuration Backup and Restoration?
Configuration backup is the process of saving a device's running or startup configuration to a persistent storage location external to the device. Restoration is the process of applying a saved configuration back to a device, either to return it to a known good state after a failure or misconfiguration, or to clone a configuration to multiple devices. These operations are fundamental to network operations because they enable rapid recovery from hardware failures, human errors, and security breaches.
Why Configuration Backup Matters for the Exam
The CompTIA Network+ N10-009 exam expects you to understand the differences between backup methods, the protocols used (TFTP, FTP, SFTP, SCP), and the steps to restore a configuration. You should also know the difference between backing up the running-config vs. startup-config, and the importance of versioning and off-site storage. Exam questions often present scenarios where a network engineer must choose the appropriate backup method or recover from a failed upgrade.
Backup Methods and Protocols
Local Backup: Saving the configuration to the device's local storage (e.g., flash memory). This is fast but not safe if the device fails completely. Example command on Cisco IOS: copy running-config startup-config or copy running-config flash:config-backup.txt.
Remote Backup using TFTP: Trivial File Transfer Protocol (TFTP) uses UDP port 69, no authentication, and no encryption. It is simple but insecure—only suitable for lab or trusted networks. Example: copy running-config tftp://192.168.1.100/config-backup.txt.
Remote Backup using FTP: File Transfer Protocol (FTP) uses TCP ports 20 and 21, supports authentication, but sends credentials and data in cleartext. Better than TFTP but still insecure over untrusted networks.
Remote Backup using SCP: Secure Copy Protocol uses SSH (TCP port 22) for encrypted file transfer. This is the recommended method for production networks. Example: copy running-config scp://user@192.168.1.100/config-backup.txt.
Remote Backup using SFTP: SSH File Transfer Protocol also runs over SSH and provides encryption. It is functionally similar to SCP but uses a different protocol.
Automated Backup via Network Management Systems (NMS): Tools like SolarWinds, PRTG, or RANCID can automatically back up configurations on a schedule. This is a best practice for large networks.
Step-by-Step Backup Process
Initiate backup: The network engineer issues a copy command or the NMS triggers a backup.
File transfer: The device sends the configuration file to the destination server using the specified protocol. For TFTP, the device acts as a TFTP client; for SCP, it uses SSH.
Verification: The engineer should verify the backup file exists on the server and check its integrity (e.g., compare file size or checksum).
Versioning: Rename the file to include a timestamp or version number (e.g., router-config-2025-03-15.txt).
Off-site storage: Copy the backup to a different physical location or cloud storage to protect against site-wide disasters.
Restoration Process
Restoration is the reverse: copying a saved configuration file to the device and either replacing the startup-config or applying it as the running-config. Common scenarios:
Replace startup-config and reboot: copy tftp://192.168.1.100/config-backup.txt startup-config followed by reload. The device boots with the saved configuration.
Replace running-config directly: copy tftp://192.168.1.100/config-backup.txt running-config. This merges the saved config with the current running config—be cautious as it may cause conflicts.
Configuration replace (Cisco IOS): The configure replace command allows atomic rollback. Example: configure replace tftp://192.168.1.100/config-backup.txt. This command compares the current running config with the saved config and applies only the differences, with an option to roll back if the new config causes connectivity loss.
Key Differences: Running vs. Startup Configuration
Running-config: The active configuration currently used by the device. Changes take effect immediately but are lost on reboot unless saved.
Startup-config: The configuration loaded when the device boots. It is stored in NVRAM (non-volatile RAM) on Cisco devices.
Backup best practice: Always back up both the running-config and startup-config. On Cisco IOS, copy running-config startup-config saves the running config to startup config. To back up the startup config separately: copy startup-config tftp://....
Configuration Versioning and Change Management
Versioning is the practice of keeping multiple dated copies of configuration files. This allows you to revert to any previous state. For example, before making a change, back up the current config with a timestamp: copy running-config tftp://.../router-before-change-2025-03-15.txt. If the change causes issues, you can restore the previous version.
Change management integrates with backups: every approved change should be preceded by a backup and followed by a backup. This creates an audit trail.
Verification and Testing
A backup is only useful if it can be restored successfully. Therefore, you must periodically test restoration by:
Loading the backup config onto a test device or a virtual instance.
Verifying that all interfaces come up, routing protocols establish neighbors, and security policies are applied.
Checking that the device can communicate with the rest of the network.
Security Considerations
Encryption: Use SCP or SFTP instead of TFTP or FTP to protect configuration data in transit.
Access control: Restrict access to backup files on the server. Configuration files often contain passwords (even if encrypted) and network topology details.
Integrity: Use checksums (MD5, SHA) to verify that backup files have not been tampered with.
Common Pitfalls
Backing up only the startup-config: If the device has unsaved changes, the backup may not reflect the current operational state.
Using TFTP over the internet: TFTP has no security and can be intercepted or spoofed.
Not testing restores: A backup file may be corrupt or incomplete; testing ensures it works.
Overwriting the only backup: Always keep multiple versions.
Interplay with Other Technologies
SNMP: Network management systems use SNMP to poll devices and trigger backups.
Syslog: Can log backup and restore events for auditing.
NTP: Accurate timestamps on backup files require synchronized clocks via NTP.
VLANs and STP: After restoration, VLAN configurations and spanning-tree parameters must be verified to avoid loops or segmentation issues.
Command Summary
| Operation | Cisco IOS Command |
|-----------|-------------------|
| Backup running-config to TFTP | copy running-config tftp://server/file |
| Backup startup-config to TFTP | copy startup-config tftp://server/file |
| Restore from TFTP to startup-config | copy tftp://server/file startup-config |
| Restore from TFTP to running-config | copy tftp://server/file running-config |
| Save running to startup | copy running-config startup-config |
| Configuration replace | configure replace tftp://server/file |
| Show current configuration | show running-config |
| Show startup configuration | show startup-config |
Advanced: Configuration Rollback
Cisco IOS supports a rollback feature using the configure replace command with the rollback keyword. For example:
configure replace tftp://192.168.1.100/good-config.txt rollback 5This applies the saved config but gives the device 5 minutes to confirm connectivity. If the engineer does not confirm within 5 minutes, the device automatically reverts to the previous configuration. This is a safety net to prevent lockout.
Summary
Configuration backup and restoration are essential network operations. The N10-009 exam focuses on understanding the methods, protocols, and best practices. Remember to always back up before making changes, use secure protocols for remote transfers, version your backups, and test restores regularly.
Initiate Backup Command
The network engineer issues a command like `copy running-config tftp://192.168.1.100/backup.cfg` from the device's CLI. The device initiates a TFTP client session to the server on UDP port 69. The device first sends a read request (RRQ) to the server, but since it is a write operation, it actually sends a write request (WRQ). The server responds with an acknowledgment, and the device transmits the configuration file in 512-byte blocks. Each block must be acknowledged before the next is sent. If any block is lost, the transfer fails. The engineer should verify the file size on the server matches the device's configuration size.
Verify Backup Completion
After the transfer, the engineer checks that the file exists on the TFTP server with the correct name and size. On the device, the command `dir flash:` can show local files if the backup was to flash. For remote backups, the engineer may use `show file` or check the server's directory. It is crucial to verify that the backup is complete and not truncated. A common mistake is to assume success without verification, leading to a corrupt backup that fails during restoration.
Version the Backup File
The engineer renames the backup file to include a timestamp or version number, e.g., `backup-2025-03-15.cfg`. This is done on the server side. Versioning allows easy identification of the most recent backup and enables rollback to any previous state. Without versioning, the latest backup overwrites the previous one, making it impossible to revert to an earlier configuration. In enterprise environments, backup scripts automatically append timestamps.
Store Backup Off-Site
The backup file is copied to a separate physical location or cloud storage. This protects against site-wide disasters like fire, flood, or theft. For example, the TFTP server might be in the same server room; an off-site copy could be on a remote FTP server or cloud storage like AWS S3. The engineer ensures the off-site location is accessible and secure. This step is often automated via scripts that sync backups to a remote site daily.
Test Restoration on Lab Device
Before relying on a backup, the engineer tests the restoration process on a lab device or virtual instance. They copy the backup file to the test device using `copy tftp://... startup-config`, then reload. After boot, they verify that interfaces are up, routing protocols have neighbors, and management access works. This step catches corrupt backups or missing configuration sections. If the test fails, the engineer troubleshoots the backup process and creates a new backup.
Perform Actual Restoration
When a device fails or a misconfiguration occurs, the engineer copies the backup file to the device's startup-config and reboots. Alternatively, they use `configure replace` for a live rollback. During the reload, the device reads the startup-config from NVRAM and applies it. The engineer monitors the console for errors. After the device comes up, they verify full functionality: ping test, interface status, routing table, and security policies. If using `configure replace`, they confirm the rollback timer if set.
In a large enterprise with hundreds of routers and switches, configuration backup is automated using a network management system like SolarWinds or RANCID. Every night, the NMS connects to each device via SSH, executes show running-config, and saves the output to a file named with the device hostname and date. The files are stored on a central file server with version control (e.g., Git). This allows engineers to see what changed over time and roll back to any previous version. A common problem is that some devices have different enable passwords or SSH keys, causing the backup to fail. Engineers must maintain a secure credential store and update it when passwords change.
Another scenario is disaster recovery after a hardware failure. A core switch dies and is replaced with an identical model. The engineer restores the backup configuration from the file server using SCP. However, if the replacement switch has a different hardware revision, some interface names may differ (e.g., GigabitEthernet0/1 vs. GigabitEthernet1/0/1). The restoration fails because the configuration references non-existent interfaces. To avoid this, engineers should maintain a 'golden' configuration template that is hardware-agnostic, or they must manually adjust the backup before applying.
A third scenario involves a security incident where an attacker modified the running-config to add a backdoor. The network team detects the change via a configuration audit (comparing current config to last known good backup). They use configure replace to roll back to the pre-attack configuration. The rollback timer is set to 10 minutes to ensure they don't lose connectivity. After the rollback, they investigate how the attacker gained access and implement additional security measures. This scenario highlights the importance of frequent backups and the ability to detect unauthorized changes.
Performance considerations: Backing up hundreds of devices simultaneously can overwhelm the TFTP server or network. Engineers schedule backups in staggered windows (e.g., different groups of devices at different times). They also limit the number of concurrent transfers per server. For large configuration files (e.g., switches with thousands of VLANs), the backup may take several minutes. Using SCP instead of TFTP reduces transfer time because SCP uses TCP with windowing, but it also increases server CPU load. Engineers must balance speed and resource usage.
Misconfiguration pitfalls: A common mistake is backing up the startup-config instead of the running-config. If the device had unsaved changes, the backup is outdated. Another mistake is forgetting to back up the configuration after making critical changes—if a failure occurs before the next scheduled backup, the latest changes are lost. Engineers should adopt a 'backup before change' policy: manually trigger a backup immediately before any modification.
The N10-009 exam tests configuration backup and restoration under Objective 3.2: Given a scenario, implement network configuration management. You must know the differences between backup methods (local, TFTP, FTP, SCP, SFTP) and when to use each. Expect scenario-based questions: e.g., 'A network engineer needs to back up the configuration of a router over an untrusted network. Which protocol should be used?' The correct answer is SCP or SFTP because they provide encryption. The wrong answer is TFTP or FTP because they send data in cleartext. Candidates often choose TFTP because it is simple, but they overlook the security requirement.
Common wrong answers and why:
1. Choosing TFTP for production backup: TFTP is fast and easy, but it lacks security. The exam expects you to choose SCP for secure transfers.
2. Backing up running-config only: Some candidates think backing up startup-config is enough, but running-config may have unsaved changes. The exam tests that you should back up both or at least the running-config.
3. Restoring by copying to running-config without merging: If you copy a full config to running-config, it replaces the current running config but does not remove commands that are not in the backup. This can leave unwanted commands active. The exam may ask about the correct method: copy to startup-config and reload, or use configure replace.
4. Assuming backup and restore are symmetric: Just because you can back up using TFTP doesn't mean restoration works the same way. For example, TFTP may have file size limits. The exam expects you to know that restoration requires the device to have the same or compatible hardware/software.
Specific numbers and terms that appear on the exam:
TFTP uses UDP port 69.
FTP uses TCP ports 20 and 21.
SCP uses TCP port 22 (SSH).
The default configuration file names are running-config and startup-config (Cisco).
The command to save running-config to startup-config is copy running-config startup-config.
The command to back up to a TFTP server is copy running-config tftp://<server-ip>/<filename>.
Edge cases the exam loves:
- Backup fails due to insufficient disk space on server: What should the engineer do? Free up space or use a different server.
- Restoration after hardware replacement with different interface names: The backup may not apply directly; engineer must edit the config or use a template.
- Configuration replace rollback timer: If the timer expires and connectivity is lost, the device reverts. The exam may ask about the purpose of the rollback parameter.
How to eliminate wrong answers:
If the scenario mentions 'security' or 'untrusted network', eliminate TFTP and FTP.
If the scenario is about 'quick backup in a lab', TFTP might be acceptable.
If the question asks about 'best practice', choose SCP and versioning.
If the question is about 'recovering from a misconfiguration', consider configure replace with rollback.
Focus on understanding the underlying mechanism: backup is a file transfer; restoration is applying that file. Know the commands and protocols.
Always back up the running-config, not just the startup-config.
Use SCP or SFTP for secure remote backups; avoid TFTP on untrusted networks.
Version backup files with timestamps to enable rollback to any previous state.
Store backups off-site to protect against site-wide disasters.
Test restoration regularly to ensure backups are valid and usable.
Use `configure replace` with rollback timer for safe configuration changes.
TFTP uses UDP port 69; SCP uses TCP port 22.
The command `copy running-config startup-config` saves the current config to NVRAM.
These come up on the exam all the time. Here's how to tell them apart.
TFTP
Uses UDP port 69
No authentication or encryption
Simple and fast, but insecure
Best for lab or trusted networks
No directory listing; must know exact filename
SCP
Uses TCP port 22 (SSH)
Provides encryption and authentication
Slower due to encryption overhead
Recommended for production and untrusted networks
Supports directory navigation and wildcards
Mistake
Backing up the startup-config is sufficient because it persists across reboots.
Correct
The startup-config only reflects the configuration at the last save. If changes were made to the running-config after the last save, they are not included in the startup-config. Always back up the running-config to capture the current operational state.
Mistake
TFTP is secure enough for internal network backups.
Correct
TFTP has no authentication or encryption. Any device on the network can intercept the backup file or spoof the server. For production networks, use SCP or SFTP which provide encryption and authentication via SSH.
Mistake
Restoring a configuration by copying to running-config is equivalent to reloading with the startup-config.
Correct
Copying to running-config merges the saved config with the current running config. Commands not present in the saved config remain active. To get a clean state, copy to startup-config and reload, or use `configure replace` which performs a diff-based replacement.
Mistake
Once a backup is created, it is safe to rely on it indefinitely.
Correct
Backups can become corrupt, or the device's hardware/software may change. Always test restoration periodically, especially after major network changes or upgrades.
Mistake
Configuration replace with rollback timer guarantees no downtime.
Correct
If the rollback timer expires and the device reverts, there may be a brief outage during the reversion. The rollback feature minimizes risk but does not eliminate it. Always have a console or out-of-band access in case of lockout.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The running-config is the active configuration currently used by the device. Changes take effect immediately but are lost on reboot unless saved. The startup-config is stored in NVRAM and is loaded at boot. Backing up the running-config captures the current state, including unsaved changes. Backing up the startup-config only captures the last saved state. For a complete backup, you should back up both, but if you can only do one, back up the running-config.
Use SCP (Secure Copy Protocol) or SFTP (SSH File Transfer Protocol). Both run over SSH and provide encryption and authentication. TFTP and FTP send data in cleartext and are not secure for internet transfers.
First, ensure the TFTP server is running and the backup file is accessible. On the router, enter global configuration mode or privileged EXEC mode. Use the command `copy tftp://<server-ip>/<filename> startup-config` to replace the startup config, then reload the router. Alternatively, use `copy tftp://<server-ip>/<filename> running-config` to merge the backup into the running config (caution: this does not remove existing commands not in the backup).
The `configure replace` command allows you to replace the current running configuration with a saved configuration file without rebooting. It compares the current config with the saved config and applies only the differences. It can also be used with a rollback timer: if connectivity is lost after the replacement, the device automatically reverts to the previous configuration after a specified time. This minimizes downtime and risk.
Use a network management system (NMS) like SolarWinds, PRTG, or RANCID. These tools can connect to devices via SSH/Telnet, execute `show running-config`, and save the output to a file server. They often support scheduling, versioning, and alerts for backup failures. Alternatively, write scripts using Python (e.g., with Netmiko or Paramiko) to automate the process.
If you discover a corrupt backup file, do not attempt to use it for restoration. Instead, try to obtain a backup from an earlier version or from another device with a similar configuration. If no clean backup exists, you may need to reconfigure the device from scratch or use a known-good configuration template. To prevent this, always verify backups immediately after creation (e.g., compare file size or checksum) and keep multiple versions.
Yes, best practice is to back up configurations of all network devices, including routers, switches, firewalls, and wireless controllers. Even devices with minimal configuration (like unmanaged switches) should be documented. In the event of a failure, having a backup saves hours of reconfiguration work and reduces the risk of human error.
You've just covered Configuration Backup and Restoration — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?