15 Backups, Upgrades and Support Resources

Keeping BIG-IP healthy over time means backing it up, upgrading it safely and knowing how to get help from F5. This note covers UCS archives, boot volumes, the HA upgrade process, the product lifecycle and F5’s support tools.

UCS archives

  • UCS (User Configuration Set) = a complete backup of the device: configuration, licenses, hostname, management IP, users, certificates and private keys.
  • Used to recover from a failed upgrade, a bad change, a disaster, or to configure an RMA replacement unit.
  • Created in System → Archives or with tmsh save /sys ucs <name>. Stored in /var/local/ucs/.

Handle UCS files like secrets

They contain private keys and password hashes. Don’t keep them only on the BIG-IP — if the box dies, the backup dies with it. Store them off-box and encrypt them.

  • Sending a UCS to F5 support: encrypt it and exclude the private keys (no-private-key).
  • Restoring on an RMA unit: use the no-license option so the new unit keeps its own license.
  • Restore: tmsh load /sys ucs <file> (or GUI → Archives → Restore), then reboot if required.

Boot volumes and software images

  • BIG-IP keeps several boot locations/volumes (HD1.1, HD1.2…). A new version is installed on an inactive volume while the current one keeps running.
  • To run the new version you set the boot location to the new volume (Activate), optionally copying the current configuration.
  • The old version stays on its volume → rollback = boot the old volume again.
  • tmsh show sys software status shows volumes, versions and the active boot location.
  • Hotfixes are installed together with their base image onto the target volume.

Upgrading an HA pair

  1. Upgrade the standby first.
  2. Fail over (Force to Standby on the active) → the upgraded unit becomes active. Test the apps.
  3. Upgrade the other unit (now standby).

Users don’t see an outage for the whole process — at most a brief interruption at failover. Avoid ConfigSync while the units run different versions.

Upgrade checklist

Before (days ahead)

  • Choose the target version: compatibility matrix (is the platform supported? are several upgrade hops needed?), release notes, known issues, security advisories fixed.
  • Check the license service check date, disk space, module support.
  • Upload a QKview to iHealth → Upgrade Advisor.
  • Open a proactive support case — you don’t have to wait for a problem.
  • Install the image on the inactive volume in advance (it doesn’t affect traffic).

During the window

  1. UCS of both units, copied off-box; QKview; note current VS/pool status.
  2. tmsh load /sys config verify → the configuration loads without errors.
  3. Activate the new volume on the standby (copying config) and reboot. Verify version, config, /var/log/ltm, object status.
  4. Force to Standby on the active; test applications.
  5. Upgrade the other unit; check sync status; test failover both ways.

After — monitor logs and performance; keep the old volume until the change is closed.

Platform and software lifecycle

MilestoneMeaning
General AvailabilityReleased
End of SaleCan’t be bought anymore
End of Software DevelopmentNo new versions/features — about 3 years after End of Sale (course rule of thumb)
End of Technical SupportNo more support cases or fixes

Software versions have their own lifecycle (Standard vs Long-Term Stability releases). Check F5’s lifecycle pages before planning upgrades or buying hardware.

Support resources

ResourceUse
my.f5.com (formerly AskF5)Knowledge base (K articles), manuals, open support cases
DevCentralCommunity forum and iRules code share
iHealth (ihealth.f5.com)Upload a QKview → heuristics, known issues, upgrade advisor, unused objects
F5 SupportCases with engineers
  • QKview = snapshot of config, logs and statistics. GUI: System → Support; CLI: tmsh run /util qkview (saved in /var/tmp/).
  • Support case — have ready: serial number / registration key, severity, clear description and timeline, QKview, captures.
  • EUD (End User Diagnostics) — hardware diagnostics preinstalled on physical appliances. You must connect with a console cable to boot into the EUD menu. Results in /shared/log/eud.log.

Self-check

Q1 — Is it a good idea to keep UCS files on the BIG-IP so you can access them quickly?

Q2 — Which three of these are included in a UCS: hostname, licenses, management IP?

Q3 — What two things should you do before sending a UCS to F5 support?

Q4 — Which option is best practice when restoring a UCS on an RMA device?

Q5 — In an HA pair, which unit is upgraded first?

Q6 — What must you do to boot the newly installed software?

Q7 — Which file holds the EUD test results, and what do you need before booting EUD?

Q8 — Which support resource is a community-driven forum?

Q9 — What is sent to the license server to generate a license?

Q10 — Roughly how long after End of Sale does End of Software Development come?