Documentation · SoftActivate Licensing Server

Backup, restore, and upgrades

Three operations are built in, all designed around one fact: your CA keys are unrecoverable, so no backup that omits them is a backup at all (certificates and keys).

Backup

# one archive = database dump + the PKI key directory + your config + a manifest
podman exec sws-licensing sws-backup > /dev/null   # writes the tar.gz inside the container
podman exec sws-licensing sws-backup /backups      # or into a mounted directory

# restore onto a fresh appliance (drop-and-load), then restart it
podman exec sws-licensing sws-restore /backups/<archive>.tar.gz

One sws-backup run produces one archive containing the database dump, the PKI key directory, your configuration, and a manifest. Schedule it like any backup job (the archive is a plain tar.gz), store it where your other cold secrets live, and record the PKI passphrase separately; a restore needs both.

Restore

sws-restore <archive> onto a fresh appliance drops and reloads the database, restores the PKI directory, and reports any drift between the archived configuration and the mounted one (it never overwrites your mounted config). Restart the appliance afterward. It is worth running a disaster drill once: a fresh host, run.sh, restore, restart. If your licenses renew and your console signs in, you know your backups work.

Upgrades

Releases follow a slow LTS tag cadence (sws-onprem-v<x>.<y>). The procedure:

  1. Back up (above, every time, no exceptions).
  2. Pull the new image tag.
  3. Recreate the container over the same volumes (re-run run.sh with the new tag, or update the tag in your Quadlet unit and restart).

The appliance steps its embedded database's compatibility version itself on first boot after an upgrade, and refuses downgrades. Going back means restoring the backup from before the upgrade onto the matching older tag. Data and keys live in the two persistent volumes; the container itself is disposable by design.

What to monitor

The built-in container healthcheck (sws-healthcheck) is the liveness signal your orchestration should watch. The server log carries the boot self-checks (PKI probe, database, scheduler). If you run the separated topology, each role reports its own health.