I have a change that operates on F5, after the first step of the change script to save the ucs file command enter, this device has been stuck in this step, during this period of time the device web interface and the backend can not be logged in, the device group did not trigger a failover, lasted for about half an hour, the device is back to normal.
I noticed that the system's "other memory" usage spiked to over 80% during the save, and gradually returned to under 30% after the system returned to normal.I didn't get any alerts and didn't do any additional operations.
How is the UCS file being created? Is it from the CLI (TMSH) or are you using the REST API?
As a first step, I would verify that the script is saving the UCS file in /var/local/ucs or /shared/tmp, and not the /root folder (as the root foler has very limited disk space).
I always use this sweet and simple UNIVESAL command for taking backup or UCS from CLI in BASH mode, as a file output will contian the F5 HOSTNAME and the accurate date & time in Hours Min seconds based on your device timezone :
tmsh save sys ucs $(echo $HOSTNAME | cut -d'.' -f1)-$(date +%H%M-%m%d%y)
Here is sample output:
[root@TESTBOX-10-mgt:ForcedOffline:Standalone] config # tmsh save sys ucs $(echo $HOSTNAME | cut -d'.' -f1)-$(date +%H%M-%m%d%y)
Saving active configuration...
/var/local/ucs/TESTBOX-10-mgt-0212-011623.ucs is saved.
You can find your UCS backup in following folder:
Connect to F5 Box using WINSCP and get the file download out of the F5 Box