Manual Backup & Restore
Configure your Cisco Router or Switch FTP settings
Iv previously configured a username: ftp1 with a password: cisco on my vsftp server. That will be used for this purpose.
Configure the clock with the current time.
CR1# clock set 11:41:00 4 April 2012
CR1#
*Apr 4 11:41:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:09:40 UTC Fri Mar 1 2002 to 11:41:00 UTC Wed Apr 4 2012, configured from console by console.
CR1# show clock
11:41:09.783 UTC Wed Apr 4 2012
CR1# CR1# conf t
CR1(config)# ip ftp username ftp1
CR1(config)# ip ftp password cisco
CR1(config)# end
CR1# CR1# copy running-config ftp:
Address or name of remote host []? 192.168.1.131
Destination filename [cr1-confg]? backup-config01
Writing backup-config01 !
833 bytes copied in 2.800 secs (298 bytes/sec)Wed Apr 4 23:42:29 2012 1 192.168.1.14 833 /backup-config01 b _ i r ftp1 ftp 0 * ccopy tftp: running-configAutomatic Local Backup using Kron
This task is configured in three steps.
Step 1. Create a kron policy-list.
This will tell what commands the router should run at the scheduled time.
CR1(config)# kron policy-list AutoSaveConfig
CR1(config-kron-policy)# cli write
CR1(config-kron-policy)# exitThis tells the router when and how often the policy should run.
CR1(config)# kron occurrence AutoSaveConfigSchedule at 00:40 Thu recurring
CR1(config-kron-occurrence)# policy-list AutoSaveConfigCR1# sh kron schedule
Kron Occurrence Schedule
AutoSaveConfigSchedule inactive, will run again in 0 days 00:05:36 at 00:35 on ThuCR1# show run | s kron
kron occurrence AutoSaveConfigSchedule at 00:35 Thu recurring
policy-list AutoSaveConfig
kron policy-list AutoSaveConfig
cli writeIll send the router’s running-config to my svftpd FTP server 192.168.1.131, every Thursday at 01:30:00.
CR1(config)# kron policy-list Backup_FTP
CR1(config-kron-policy)# cli show run | redirect ftp://192.168.1.131/ciscoback1.cfg
CR1(config-kron-policy)# exit CR1(config)# kron occurrence Backup at 01:30 Thu recurring
CR1(config-kron-occurrence)# policy-list Backup_FTP
CR1(config-kron-occurrence)# end CR1# show kron schedule
Kron Occurrence Schedule
AutoSaveConfigSchedule inactive, will run again in 0 days 00:02:00 at 1 :30 on Thu
Backup inactive, will run again in 0 days 00:01:22 at 1 :30 on Thu Thu Apr 5 01:29:48 2012 1 192.168.1.14 1044 /ciscoback1.cfg b _ i r ftp1 ftp 0 * c
And here is the confirmation in the running-config that the backup was successful.CR1# show run
Building configuration...
!
Current configuration : 1042 bytes
!
! Last configuration change at 01:25:17 UTC Thu Apr 5 2012
! NVRAM config last updated at 01:30:39 UTC Thu Apr 5 2012
One of the most important tasks of a network administrator is to backup the network configuration files of every Cisco device periodically. This periodicity is dictated and established by the organization policies. Frequency could be every week, every fifteen days or every month depending on the needs of the organization.
The importance of the configuration files of the network can be seen from many administrative perspectives:
- Compare and validate configurations between devices.
- In case of any damage of the equipment, configuration files could be used to restore the operational state of the network with a simple copy and paste of the configuration in another device.
- To rollback configurations to a previous state.
Now, imagine a network with five devices, a backup in this scenario is very simple for a network administrator. Since only five devices reside in the network, you could access via console, telnet or ssh into the router and save the configuration in a TFTP server executing the following command on every device:
R1#copy running-config tftp://<SERVER_IP>/<CONFIGURATION_FILE_NAME/
But what if you have fifty or even one hundred devices? In this type of scenario it is hard to manually perform backups. The network administrator will be subject to what is often called “administration burden” because of the amount of devices that have to be manually accessed and executed the previous command. For this type of situation, you have a variety of external options available (third party applications), but one that is often overlooked by some network administrators that is part of the feature set of your Cisco device is the Cisco IOS Auto Archive Feature.
This feature was introduced into Cisco IOS Release 12.3(4), the Archive command enables the administrator to configure snapshots of the configuration files. The configuration is straightforward.
R1#conf t
Enter configuration commands, one per line. End with Ctrl+Z.
archivepath tftp://172.16.1.10/time-period 1440log config logging enable notify syslog hidekeys
In this case we entered into the global configuration mode and use the “path” command; this set the path to an external server, in this case a TFTP with the 172.16.1.10 IP address. These are the necessary commands in order to configure a basic Archive. To test our configuration we could execute the “archive config” privilege mode command.
R1#archive config
If the TFTP is operational, it should produce the following output.
R1#archive config !!
Now we can go to the TFTP directory in order to validate if the configuration was successfully sent.
And we see how the configuration file is stored as "-1", this is because, by default, the Archive feature saves the configuration in increments of one. We can see this if we perform another manual configuration, save and execute the "show archive" command.
R1#show archive
The next archive file will be named
tftp://172.16.1.10/-3
Archive # Name
0 1 tftp://172.16.1.10/-1 2 tftp://172.16.1.10/-2 <- Most Recent 3 4 5 6 7 8 9 10 11 12 13 14
We see that in the history of the router, the archive tells us that configuration was sent to the TFTP with the name "-2" and is the most recent. In this output you can note that Archive can only maintain a maximum registry of 15 configuration files inside the router.
For administration purposes, the default naming convention is not very filexible, because it is not telling us anything about the device itself. If we want to rapidly identify a device in the directory, we can use the hostname of the device itself. For this we have two possible options: hardcode the hostname of the device or set a name variable using "$h" in order to automagically send the configuration name with the current hostname of the device.
Hostname in Path
R1(config)#archive R1(config-archive)#path tftp://172.16.1.10/R1 R1(config-archive)#exit
Note that in this case, if the hostname of the device changes in the future to, let's say, R2 the archive configuration will still send the configuration file with the name set to "R1". For this purporses we have the second mentioned option.
Hostname Variable in Path
R1(config)#archive R1(config-archive)#path tftp://192.168.2.2/$h R1(config-archive)#exit
If we manually save the configuration and then execute the "show archive" command we can see the results of the configuration.
R1#archive config !! R1#show archive
The next archive file will be named
tftp://172.16.1.10/R1-2
Archive # Name
0 1 tftp://172.16.1.10/R1-1 <- Most Recent 2 tftp://172.16.1.10/-2 3 tftp://172.16.1.10/-3 4 5 6 7 8 9 10 11 12 13 14
We can visualize that the most recent configuration file sent is named as "R1-1" which has the index set to 1.
At this point, it is very easy for an administrator to manually backup the configuration files of the devices in the network, but the problem partially persists, because this is a manual process. If we want to sort of "overcome" this we can enable the "write-memory" command inside the Archive configuration mode. This allows the router to automagically perform the backup instead of manually saving the configuration.
Time Variable in Path
We could also configure a time variable in the naming convention of the archive configuration. This is to have the date in the name of the file in the TFTP backup folder.
R1(config)#archive R1(config-archive)#path tftp://172.16.1.10/$h-$t R1(config-archive)#exit
If we execute the "archive config" command we can see that the time is set in the name of the file.
Archive Write-Memory Option
R1(config)#archive R1(config-archive)#write-memory R1(config-archive)#exit
If we execute the "write memory" or "copy running-config startup-config" commands we can see that the configuration is automatically stored in the TFTP folder.
The "copy running-config startup-config" responds with "[OK]!!" which is the acknowledgement of the TFTP. With this operation, the local configuration changes are saved and automatically sent to the TFTP server.
If we need to save the configuration file every certain amount of time, we can use the "time-period" operation. This option allows us to perform the configuration backup every certain amount time, this way we don't have to manually console, telnet or ssh into the device. The "time-period" option must be set in minutes, therefore if according to the organization policies, backups need to be executed every week, we would need to configure a time period of 10080.
Archive Time-Period Option
R1(config)#archive R1(config-archive)#time-period 10080 R1(config-archive)#exit
The next backup will be performed in one week exactly (time in minutes), but what if we would like to configure this periodicity with an explicit date time? Unfortunately with the current Archive features, it is not possible. In that case we could combine the Archive feature with Kron Schedule.
Kron is a command scheduler used to automate tasks in the Cisco IOS Software. With Kron, we can set policies and use them once or with a certain periodicity. For this we configure a Kron Policy List and then apply an occurrence to the global Kron policy. Note that Kron does not work with interactive commands, meaning commands that have some type of dialog for validation. An example would be "copy running-config startup-config". In this case, a dialog would appear in order to validate the execution of the sentence. Since we have this "limitation" with that sentence, we could use the "write memory" command which does not need any validation and use it in the Kron Policy.
in order to get a router to copy the running-config to startup-config, for example every Sunday at 23:00, complete these steps: 1 - Create a kron policy list—This is the script that lists what commands the router should run at the scheduled time. Router#enable Router#configure terminal Router(config)#kron policy-list Backup Router(config-kron-policy)#cli show startup-config | redirect tftp://192.168.1.252/test.cfg Router(config-kron-policy)#exit cli—Specifies EXEC CLI commands within a Command Scheduler policy list. policy-list—Specifies the policy list associated with a Command Scheduler occurrence. Note: The reason why write was used rather than copy running-config startup-config is because kron does not support interactive prompts and the copy running-config startup-config command requires interaction. It is important to remember this when you create commands. Also, note that kron does not support configuration commands. 2 - Create a kron occurrence—This informs the router when and how often the policy should run. Router(config)#kron occurrence SaveConfigSchedule at 23:00 Sun recurring Router(config-kron-occurrence)#policy-list Backup SaveConfigSchedule—This is the name of occurrence. Length of occurrence-name is from 1 to 31 characters. If the occurrence-name is new, an occurrence structure will be created. If the occurrence-name is not new, the existing occurrence will be edited. at—Identifies that the occurrence is to run at a specified calendar date and time. recurring—Identifies that the occurrence is to run on a recurring basis.
R2(config)#kron policy-list SystemBackup
R2(config-kron-policy)#cli write
R2(config-kron-policy)#cli cli show run | redirect tftp://10.1.1.1/test.cfg
R2(config-kron-policy)#exit
R2(config)#kron occurrence SystemBackup at 23:00 Sun recurring
R2(config-kron-occurrence)#policy-list SystemBackup
Hiç yorum yok:
Yorum Gönder