Upgrade and backup
Where each kind of state lives, what survives an upgrade, how to back up and migrate, how to downgrade.
Where state lives
| What | Where | Survives upgrade |
|---|---|---|
| LLM / embeddings / channel / ticket / threat-intel secrets | storage/passwords (Splunk-encrypted) | Yes |
| Local configuration | local/copilot.conf, local/app.conf | Yes (the installer never overwrites local/) |
| Licence, heartbeat session, feature keys | storage/passwords + local/app.conf [license] | Yes |
| Conversations, knowledge base, solutions, triage results, assets / identities, report archive, baseline rules and results, notification config and deliveries, preferences and dispositions, MCP token hashes, ticket records | KV store copilot_* collections | Yes (replicated in a cluster) |
| Audit | index=_internal sourcetype=copilot:audit | Per _internal retention |
| Deployed detection rules, searches saved as Reports, configs written by data onboarding | savedsearches.conf in the search app / the target app's local/props.conf | Independent of the app |
| Sealed detection engine | bin/detection_core.sealed | Replaced with the package |
Upgrade
Install the new .spl over the old one and restart. default/ is replaced; local/ and the KV store are untouched. Afterwards:
- Check the engine card on Settings → AI settings; the selfcontained package refreshes
bin/lib/, replacing anything vendored by hand. - Check the licence page. An online licence picks up any new feature keys at its next heartbeat; an offline licence has its feature set baked in, so a new paid feature needs a re-signed
.lic. - New KV collections are declared in
default/collections.confand created on first use. Field-type corrections incollections.conf(1.6.0 changed timestamps fromnumbertostring) apply with the package; old documents stay as they are. - Hard-refresh the browser once; Splunk Web caches static assets until the app build number changes.
Do not deactivate the licence before upgrading. Deactivation returns the online seat to the server and clears the local feature keys; the upgrade itself does not need it.
Backup
- KV store: Splunk's
splunk backup kvstore, or export eachstorage/collections/data/<collection>over REST; a cluster already replicates it. - Configuration and secrets: the whole
etc/apps/rst_splunk_ai_copilot/local/plusetc/passwd(storage/passwordsciphertext is bound to the instance'ssplunk.secret; moving to another instance needssplunk.secrettoo). - Licence fingerprint: the server GUID in
etc/instance.cfgplus the host's/etc/machine-id. Restoring onto a machine where these differ means re-activation (deactivate on the old machine first, or ask sales to release the seat).
Migrating to a new search head
- Install the same app version on the new machine.
- Copy
local/,etc/passwdandsplunk.secret(or re-enter the secrets in the UI). - Import the KV collections.
- Deactivate on the old machine, activate on the new one.
Downgrade
Install the older .spl over the current one. Collections and configuration keys added by a newer version are ignored by the older one; documents carrying unknown fields are simply not read. Versions before 1.6.0 use a different set of routes, so bookmarks break.
Roles and permissions
The three roles and their capabilities, which tier each feature needs, the Splunk permissions behind ES write-back and data onboarding, and how login stays Splunk's.
UI tour
The three navigation groups and the shift they follow, the top-bar controls, the command palette, how roles affect buttons, and the three entry points outside the navigation.