ISE Operational Backup Size

[rwehe]

After patching from 2.6 P5 to 2.6 P7 the operational backup size has increased significantly (from ~500 MB to ~25 GB). Is there any tool we have to estimate how large the operational backup should be based on endpoint database count, policies, etc?

[Arne Bier]

ISE backups contain a lot of garbage, in addition to useful data. If you want to see what's taking up the space, then copy the backup to a PC and analyse the PGP encrypted file. I find it easiest doing gpg commands on the Linux command line (or Linux shell on Windows 10).

Decrypt the PGP file

biera@linux:/mnt/c/tmp$ gpg -v --batch --yes --passphrase MySecret123 -d ISE26_WEEKLY_-CFG10-200809-0000.tar.gpg > somefile.tar

The gpg command will create a tar file called somefile.tar - extract that tar file in the current directory - it will create a folder called backup, which contains the ISE backup data

biera@linux:/mnt/c/tmp/backup$ tar xvf somefile.tar

Then sort by largest files ... this is an example of a fairly new and fresh ISE system (just built) - notice the amount of logs already captured ... what's the point of logs in a config backup? It's just garbage. The older the system, the more rubbish it carries around ...

You might find all sorts of diagnostic data in these files which are of no use to the average user. In my opinion, diagnostic data should be collected if required via a support bundle, and not via a config backup.

The uncompressed logs took up around 2.1GB ... below is a list of the top culprits of space wasters ..

biera@linux:/mnt/c/tmp/backup/ise/logs$ ls -lS
total 2011772
-rwxrwxrwx 1 biera biera 1777943270 Aug 9 00:01 caservice_bootstrap.log
-rwxrwxrwx 1 biera biera 19269399 Aug 4 23:59 ise-elasticsearch-2020-08-04-1.log
-rwxrwxrwx 1 biera biera 19267084 Aug 5 23:59 ise-elasticsearch-2020-08-05-1.log
-rwxrwxrwx 1 biera biera 19265780 Aug 3 23:59 ise-elasticsearch-2020-08-03-1.log
-rwxrwxrwx 1 biera biera 19265058 Aug 6 23:59 ise-elasticsearch-2020-08-06-1.log
-rwxrwxrwx 1 biera biera 19258407 Aug 7 23:59 ise-elasticsearch-2020-08-07-1.log
-rwxrwxrwx 1 biera biera 19257342 Aug 8 23:59 ise-elasticsearch-2020-08-08-1.log
-rwxrwxrwx 1 biera biera 9616372 Aug 5 23:59 ise-psc.log.2020-08-05.1
-rwxrwxrwx 1 biera biera 8789367 Aug 8 23:59 deployment.log.2020-08-08.1
-rwxrwxrwx 1 biera biera 8789170 Aug 4 23:59 deployment.log.2020-08-04.1
-rwxrwxrwx 1 biera biera 8789170 Aug 5 23:59 deployment.log.2020-08-05.1
-rwxrwxrwx 1 biera biera 8789009 Aug 7 23:59 deployment.log.2020-08-07.1
-rwxrwxrwx 1 biera biera 8783120 Aug 6 23:59 deployment.log.2020-08-06.1
-rwxrwxrwx 1 biera biera 8782612 Aug 3 23:59 deployment.log.2020-08-03.1

[Damien Miller]

There might be a terminology difference here. Most don't backup what ISE refers to as the operational backups and just accept that if the monitoring nodes fail they will lose the historical reporting. Considering these are at most 30 days by default, most customers I work with choose to export them via syslog to something like Splunk anyways. Losing the operational logs can be an admin impact, but isn't an issue from a functional deployment standpoint. 

Now if your configuration backup went form 500 MB to 25 GB, then there is an issue and Arne's post can provide some insight as to why it can happen. I would first check to see if any debugs are enabled still. 

So which one has increased? Cisco ISE allows you to back up the following type of data:

• Configuration data—Contains both application-specific and Cisco ADE operating system configuration data. Back up can be done via the Primary PAN using the GUI or CLI.

• Operational Data—Contains monitoring and troubleshooting data. Back up can be done via the Primary PAN GUI or using the CLI for the Monitoring node.