You can use the CLI and GUI to create repositories. We recommend that you use the GUI due to the following reasons:

• Repositories that are created through the CLI are saved locally and do not get replicated to the other deployment nodes. These repositories do not get listed in the GUI’s repository page.

• Repositories that are created on the primary administration node get replicated to the other deployment nodes.

You can perform an On-demand backup to instantly backup the configuration or monitoring (operational) data. The restore operation restores Cisco ISE to the configuration state that existed at the time of obtaining the backup.

You can use this page to schedule configuration or monitoring backups.

Although you can schedule backups both from the CLI as well as the GUI, it is recommended to use GUI for better options. But, you can perform Operational backup on the secondary monitoring node only from the CLI.

Backup history provides basic information about scheduled and on-demand backups. It lists the name of the backup, backup file size, repository where the backup is stored, and time stamp that indicates when the backup was obtained. This information is available in the Operations Audit report and on the Backup and Restore page in the History table.

For failed backups, Cisco ISE triggers an alarm. The backup history page provides the failure reason. The failure reason is also cited in the Operations Audit report. If the failure reason is missing or is not clear, you can run the backup-logs command from the Cisco ISE CLI and look at the ADE.log for more information.

While the backup operation is in progress, you can use the show backup status CLI command to check the progress of the backup operation.

Backup history is stored along with the Cisco ADE operating system configuration data. It remains there even after an application upgrade and are only removed when you reimage the primary administration node.

If backup fails, check the following:

• Make sure that no other backup is running at the same time.

• Check the available disk space for the configured repository.

  • Monitoring backup fails if the monitoring data takes up more than 75% of the allocated monitoring database size. For example, if your Monitoring node is allocated 600 GB, and the monitoring data takes up more than 450 GB of storage, then monitoring backup fails.

  • If the database disk usage is greater than 90%, a purge occurs to bring the database size to less than or equal to 75% of its allocated size.

• Verify if a purge is in progress. Backup and restore operations will not work while a purge is in progress.

• Verify if the repository is configured correctly.

Following are guidelines to follow when you restore Cisco ISE backup data.

• If you obtain a backup from your primary Administration node in one timezone and try to restore it on another Cisco ISE node in another timezone, the restore process might fail. This failure happens if the timestamp in the backup file is later than the system time on the Cisco ISE node on which the backup is restored. If you restore the same backup a day after it was obtained, then the timestamp in the backup file is in the past and the restore process succeeds.

• When you restore a backup on a primary Cisco ISE node with a different hostname than the one from which the backup was obtained, the primary Cisco ISE node becomes a standalone node. The deployment is broken and the secondary nodes become nonfunctional. You must make the standalone node the primary node, reset the configuration on the secondary nodes, and reregister them with the primary node. To reset the configuration on Cisco ISE nodes, enter the following command from the Cisco ISE CLI:

  • application reset-config ise

• We recommend that you do not change the system timezone after the initial Cisco ISE installation and setup.

• If you changed the certificate configuration on one or more nodes in your deployment, you must obtain another backup to restore the data from the standalone Cisco ISE node or primary Administration node (PAN). Otherwise, if you try to restore data using an older backup, the communication between the nodes might fail.

• After you restore the configuration backup on the PAN, you can import the Cisco ISE CA certificates and keys that you exported earlier.

  Note	If you did not export the Cisco ISE CA certificates and keys, then after you restore the configuration backup on the PAN, generate the root CA and subordinate CAs on the PAN and Policy Service Nodes (PSNs).

• You need a data repository, which is the location where Cisco ISE saves your backup file. You must create a repository before you can run an on-demand or scheduled backup.

• If you have a standalone administration node that fails, you must run the configuration backup to restore it. If your primary Administration node fails, you can use the distributed setup to promote your secondary Administration node to become the primary. You can then restore data on your primary Administration node after it comes up.

  Note	Cisco ISE also provides the backup-logs CLI command that you can use to collect log and configuration files for troubleshooting purposes.

Defaults

To restore configuration data through the Cisco ISE CLI, use the restore command in the EXEC mode. Use the following command to restore data from a configuration or operational backup:

restore filename repository repository-name encryption-key hash|plain encryption-key name include-adeos

Syntax Description

No default behavior or values.

EXEC

When you use restore commands in Cisco ISE, the Cisco ISE server restarts automatically.

The encryption key is optional while restoring data. To support restoring earlier backups where you have not provided encryption keys, you can use the restore command without the encryption key.

ise/admin# restore mybackup-100818-1502.tar.gpg repository myrepository encryption-key plain Lab12345
Restore may require a restart of application services. Continue? (yes/no) [yes] ? yes
Initiating restore.  Please wait...
ISE application restore is in progress.
This process could take several minutes. Please wait...
Stopping ISE Application Server...
Stopping ISE Monitoring & Troubleshooting Log Processor...
Stopping ISE Monitoring & Troubleshooting Log Collector...
Stopping ISE Monitoring & Troubleshooting Alert Process...
Stopping ISE Monitoring & Troubleshooting Session Database...
Stopping ISE Database processes...
Starting ISE Database processes...
Starting ISE Monitoring & Troubleshooting Session Database...
Starting ISE Application Server...
Starting ISE Monitoring & Troubleshooting Alert Process...
Starting ISE Monitoring & Troubleshooting Log Collector...
Starting ISE Monitoring & Troubleshooting Log Processor...
Note: ISE Processes are initializing. Use 'show application status ise'
      CLI to verify all processes are in running state.
ise/admin#

If the sync status and replication status after application restore for any secondary node is Out of Sync, you have to reimport the certificate of that secondary node to the primary administration node and perform a manual synchronization.

You can restore a configuration backup from the Admin portal. The GUI lists only the backups that are taken from Cisco ISE, Release 1.2. To restore backups that are prior to this release, use the restore command from the CLI.

You can obtain information about all restore operations, log events, and statuses from the Operations Audit report.

Note	However, the Operations Audit report does not provide information about the start times corresponding to the previous restore operations.

For troubleshooting information, you have to run the backup-logs command from the Cisco ISE CLI and look at the ADE.log file.

While the restore operation is in progress, all Cisco ISE services are stopped. You can use the show restore status CLI command to check the progress of the restore operation.

Scenario

In a distributed deployment, a natural disaster leads to a loss of all the nodes. After recovery, you want to use the existing IP addresses and hostnames.

For example, you have two nodes: N1 (primary Administration node) and N2 (secondary Administration node.) A backup of the N1 node, which was taken at time T1, is available. Later, both N1 and N2 nodes fail because of a natural disaster.

Assumption

All Cisco ISE nodes in the deployment were destroyed. The new hardware was imaged using the same hostnames and IP addresses.

Resolution Steps

1. You have to replace both the N1 and N2 nodes. N1 and N2 nodes will now have a standalone configuration.

2. Obtain a license with the UDI of the N1 and N2 nodes and install it on the N1 node.

3. You must then restore the backup on the replaced N1 node. The restore script will try to sync the data on N2, but N2 is now a standalone node and the sync will fail. Data on N1 will be reset to time T1.

4. You must log in to the N1 Admin portal to delete and reregister the N2 node. Both the N1 and N2 nodes will have data reset to time T1.

Scenario

In a distributed deployment, a natural disaster leads to loss of all the nodes. The new hardware is reimaged at a new location and requires new IP addresses and hostnames.

For example, you have two ISE nodes: N1 (primary Administration node) and N2 (secondary Policy Service node.) A backup of the N1 node which was taken at time T1, is available. Later, both N1 and N2 nodes fail because of a natural disaster. The Cisco ISE nodes are replaced at a new location and the new hostnames are N1A (primary Administration node) and N2A (secondary Policy Service node). N1A and N2A are standalone nodes at this point in time.

Assumptions

All Cisco ISE nodes in the deployment were destroyed. The new hardware was imaged at a different location using different hostnames and IP addresses.

Resolution Steps

1. Obtain the N1 backup and restore it on N1A. The restore script will identify the hostname change and domain name change, and will update the hostname and domain name in the deployment configuration based on the current hostname.

2. You must generate a new self-signed certificate.

3. You must log in to the Cisco ISE Admin portal on N1A, choose Administration > System > Deployment, and do the following:

   Delete the old N2 node.

   Register the new N2A node as a secondary node. Data from the N1A node will be replicated to the N2A node.

Scenario

A standalone administration node is down.

For example, you have a standalone administration node, N1. A backup of the N1 database was taken at time T1. The N1 node goes down because of a physical failure and must be reimaged or a new hardware is required. The N1 node must be brought back up with the same IP address and hostname.

Assumptions

This deployment is a standalone deployment and the new or reimaged hardware has the same IP address and hostname.

Resolution Steps

Once the N1 node is up after a reimage or you have introduced a new Cisco ISE node with the same IP address and hostname, you must restore the backup taken from the old N1 node. You do not have to make any role changes.

Scenario

A standalone administration node is down.

For example, you have a standalone administration node, N1. A backup of the N1 database taken at time T1 is available. The N1 node is down because of a physical failure and will be replaced by a new hardware at a different location with a different IP address and hostname.

Assumptions

This is a standalone deployment and the replaced hardware has a different IP address and hostname.

Resolution Steps

1. Replace the N1 node with a new hardware. This node will be in a standalone state and the hostname is N1B.

2. You can restore the backup on the N1B node. No role changes are required.

Problem

There may be instances where you inadvertently make configuration changes that you later determine were incorrect. For example, you may delete several NADs or modify some RADIUS attributes incorrectly and realize this issue several hours later. In this case, you can revert back to the original configuration by restoring a backup that was taken before you made the changes.

Possible Causes

There are two nodes: N1 (primary Administration node) and N2 (secondary Administration node) and a backup of the N1 node is available. You made some incorrect configuration changes on N1 and want to remove the changes.

Solution

Obtain a backup of the N1 node that was taken before the incorrect configuration changes were made. Restore this backup on the N1 node. The restore script will sync the data from N1 to N2.

Scenario

In a multinode deployment, the primary administration node fails.

For example, you have two Cisco ISE nodes, N1 (primary Administration node) and N2 (secondary Administration node). N1 fails because of hardware issues.

Assumptions

Only the primary node in a distributed deployment has failed.

Resolution Steps

1. Log in to the N2 Admin portal. Choose Administration > System > Deployment and configure N2 as your primary node.

   The N1 node is replaced with a new hardware, reimaged, and is in the standalone state.

2. From the N2 Admin portal, register the new N1 node as a secondary node.

   Now, the N2 node becomes your primary node and the N1 node becomes your secondary node.

If you wish to make the N1 node the primary node again, log in to the N1 Admin portal and make it the primary node. N2 automatically becomes a secondary server. There is no data loss.

Scenario

In a multinode deployment, a single secondary node has failed. No restore is required.

For example, you have multiple nodes: N1 (primary Administration node), N2 (secondary Administration node), N3 (secondary Policy Service node), N4 (secondary Policy Service node). One of the secondary nodes, N3, fails.

Resolution Steps

1. Reimage the new N3A node to the default standalone state.

2. Log in to the N1 Admin portal and delete the N3 node.

3. Reregister the N3A node.

   Data is replicated from N1 to N3A. No restore is required.