Configuration Backup and Restore
Lab Objectives
- Back up and restore device configurations using TFTP to a central server (199.1.1.5).
- Demonstrate file transfer to/from router flash and the server using the URI copy method.
- Explain basic IOS image/config file management concepts and verify transfers.
Lab Tasks (Try It Yourself First!)
Complete these tasks WITHOUT looking at the solution below. Use
?andshowcommands to figure it out.
Task 1: Backup the running configuration of R1 to the TFTP server
Save the active running configuration on R1 to the TFTP server located at 199.1.1.5 and name the file R1-running.cfg. Do not change interfaces or routing — only perform the backup.
Task 2: Restore a configuration to R2 from the TFTP server
On R2, retrieve a saved configuration file named R2-startup.cfg from the TFTP server 199.1.1.5 and place it into the router's flash. Do NOT automatically reload the router; place the file so you can examine and apply it manually.
Task 3: Upload an image or file to R1 flash (example file transfer)
Using the TFTP server 199.1.1.5, copy a file named example.bin to R1's flash to demonstrate how IOS images or other binaries are uploaded to flash using the URI style transfer.
Think About It: Why is it safer in production to transfer a configuration to flash first, inspect it, then apply it — instead of directly overwriting the running or startup configuration on a router?
Lab Solution
Task 1 Solution: Backup the running configuration of R1 to the TFTP server
What we are doing: We save the current active configuration to a file on the TFTP server. This gives us a point-in-time backup we can restore later if needed. In production, routine backups protect against configuration drift and accidental changes.
R1#copy running-config tftp:
Address or name of remote host []? 199.1.1.5
Destination filename [running-config]? R1-running.cfg
What just happened:
copy running-config tftp:initiates a transfer of the device's current memory configuration to a TFTP server. This is the standard IOS method for off-box backups.- The CLI prompts for the remote host (199.1.1.5) and destination filename (R1-running.cfg). Using a descriptive filename avoids confusion when you maintain many backups.
Why this matters:
- Backing up the live configuration ensures you capture the exact active state (interfaces, routes, ACLs).
- Storing the file off the device (on 199.1.1.5) protects the backup in case the router's flash fails.
Verify:
! On the TFTP server (199.1.1.5) – expected: a file exists
# ls -l /tftpboot/R1-running.cfg
-rw-r--r-- 1 admin admin 4096 Apr 1 12:30 R1-running.cfg
! On R1, confirm nothing changed in running config
R1#show running-config
Building configuration...
Current configuration : 1024 bytes
!
version 15.2
hostname R1
!
interface GigabitEthernet0/0
ip address 10.10.10.1 255.255.255.0
!
! (rest of running-config displayed)
Tip: If the TFTP server does not show the file, check network connectivity (ping from R1 to 199.1.1.5) and ensure the server's TFTP daemon is running and the tftp root folder permissions allow writes.
Task 2 Solution: Restore a configuration to R2 from the TFTP server
What we are doing: We copy a saved configuration file from the TFTP server into R2's flash. We will not immediately apply it; instead we place it in flash so we can inspect and optionally load it as the running or startup config. This is a safe restore workflow.
R2#copy tftp://199.1.1.5/R2-startup.cfg flash:R2-startup.cfg
Address or name of remote host []? 199.1.1.5
Source filename []? R2-startup.cfg
Destination filename [R2-startup.cfg]? R2-startup.cfg
What just happened:
copy tftp://199.1.1.5/R2-startup.cfg flash:R2-startup.cfguses a URI-style source to pull the file from the TFTP server into the router's flash storage. This is the inverse operation of Task 1.- Placing the file in flash preserves the existing startup and running configs until you intentionally load the file.
Why this matters:
- Restoring to flash first prevents an accidental immediate config overwrite. You can
more flash:R2-startup.cfgto inspect before committing. - In production, admins often restore to flash, verify differences, and then merge or replace configs during a maintenance window.
Verify:
R2#dir flash:
Directory of flash:/
2 -rwx 4096 Apr 1 12:00 R2-startup.cfg
3 -rwx 2097152 Mar 30 09:01 old-image.bin
4 -rwx 1024 Feb 28 08:00 notes.txt
25000000 bytes total (18000000 bytes free)
R2#more flash:R2-startup.cfg
!
version 15.2
hostname R2
!
interface GigabitEthernet0/0
ip address 10.10.10.2 255.255.255.0
!
! (rest of the restored config displayed)
Warning: After you inspect, if you want to make the file the active config you can either copy it into startup-config or merge parts into the running-config. Do this during a maintenance window if services will be affected.
Task 3 Solution: Upload an image or file to R1 flash (example file transfer)
What we are doing: We copy a binary (example.bin) from the TFTP server into R1's flash. This mimics copying an IOS image or other firmware/utility files to the device.
R1#copy tftp://199.1.1.5/example.bin flash:example.bin
Address or name of remote host []? 199.1.1.5
Source filename []? example.bin
Destination filename [example.bin]? example.bin
What just happened:
- The URI-style
copypulls example.bin onto the router's flash. This is the standard method to stage IOS images before you verify and change the boot variable. - Staging allows you to validate checksum, compatibility, and free space before modifying boot parameters.
Why this matters:
- In production, IOS image management is critical. You stage images in flash, verify integrity (checksums), and only then change the boot variable and reload during a maintenance window.
- This staged approach avoids bricking devices due to incomplete transfers.
Verify:
R1#dir flash:
Directory of flash:/
1 -rwx 31457280 Apr 1 12:35 example.bin
2 -rwx 4096 Mar 31 10:00 R1-running.cfg
3 -rwx 12345 Feb 20 09:00 readme.txt
25000000 bytes total (12000000 bytes free)
R1#verify /md5 flash:example.bin
Verifying /md5 flash:example.bin ... MD5 digest: 5d41402abc4b2a76b9719d911017c592
Tip: Always check free flash space before copying large image files. If insufficient, remove unnecessary files first.
Troubleshooting Scenario
Scenario: Backup to TFTP fails with timeout
Symptom: When executing copy running-config tftp:, the router hangs and eventually times out; file never appears on 199.1.1.5.
Your task: Find and fix the issue.
Hint: TFTP is UDP-based and requires the server to be reachable; also firewalls or incorrect server root folders commonly cause problems.
Solution:
- From the router, verify connectivity to the server:
R1#ping 199.1.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 199.1.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
- If ping fails, check network path, IP addressing, and routes between the router and server.
- Ensure the TFTP daemon is running on 199.1.1.5 and that the destination directory permits writes:
- On the server: confirm the tftp root folder exists and permissions are correct; restart the TFTP service.
- If ping works but the transfer still times out, check switch ACLs or host-based firewalls that may block UDP port 69.
Verification Checklist
- You successfully copied R1 running-config to 199.1.1.5 as R1-running.cfg.
- You copied R2-startup.cfg from 199.1.1.5 into R2 flash and inspected it.
- You staged example.bin on R1 flash and verified its presence.
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| TFTP copy times out | TFTP server unreachable or blocked by firewall | Verify ping to 199.1.1.5; enable/allow UDP 69 on the server and network devices |
| “No space left” when copying image | Insufficient flash space on router | Delete unneeded files from flash and retry; confirm free space with dir flash: |
| copied file corrupt or checksum mismatch | Transfer interrupted or server file corrupted | Re-transfer; verify MD5 checksum on both server and router |
Challenge Task
Stage a configuration restore workflow for R3 that:
- Pulls a saved config from 199.1.1.5 into flash as R3-candidate.cfg
- Compares the candidate file against the current running configuration and displays the differences
- Apply only the interface-related sections from the candidate to the running configuration without a full overwrite
(You will need to design commands and inspection steps. Think about saving running-config, using the staged file, and applying selective changes.)
Real-world context: In production networks, configuration backups and image staging are part of standard change control. You should always stage files off-device, verify checksums and free space, and apply changes during maintenance windows to minimize service impact. Think of the TFTP server as a shared vault — safe backups let you recover quickly after failures or misconfiguration.