Upgrade, rollback and backup

Upgrading

Option 1: new archive, deploy.sh in the same directory

Unpack the new archive into the same directory (scripts and compose files are overwritten, .env and state/ are not) and run it again:

tar xzf RST-Qradar-AI-Copilot-<new>.tar.gz --strip-components=1 -C /opt/rst-copilot
cd /opt/rst-copilot && ./deploy.sh      # "keep existing .env and start?" → Y

It docker loads every image tar in the directory and takes the newest tag, switches GATEWAY_IMAGE_TAG, restarts with --force-recreate and waits for healthy. Afterwards confirm docker inspect rst-qradar-ai-copilot-gateway --format '{{.Config.Image}}' shows the new version. Old RST-Qradar-AI-Copilot-images-*.tar files can be deleted or left; they do no harm.

Option 2: online update

A gateway with an online licence learns about new versions through the heartbeat. Click "Download and stage" under Settings → Version and updates; the gateway verifies the signature and stores the image under ./release/staging. Then on the host:

./deploy/rst-update.sh              # load staged image → switch GATEWAY_IMAGE_TAG → health probe
./deploy/rst-update.sh --rollback   # back to the previous version

Success needs three consecutive 200s from /healthz; otherwise it rolls back automatically.

Option 3: manual

docker load < RST-Qradar-AI-Copilot-images-<new>.tar
sed -i 's/^GATEWAY_IMAGE_TAG=.*/GATEWAY_IMAGE_TAG=<new>/' .env
docker compose -f docker-compose.prod.yml up -d

Rollback

Restart on the previous tag:

sed -i 's/^GATEWAY_IMAGE_TAG=.*/GATEWAY_IMAGE_TAG=<previous>/' .env
docker compose -f docker-compose.prod.yml up -d

Licence state lives in state/ and the gateway_state volume, not in the image, so it survives. Tables in copilot.db are created on demand at startup; an older version ignores tables a newer one added.

What to back up

Events, offenses and rules on the QRadar side are not the gateway's to back up: offenses in the gateway are copies, and after deletion the next sync pulls them again within RST_OFFENSE_INGEST_LOOKBACK. Only the AI summaries and dispositions would be lost.

Gateway state

bash scripts/backup.sh /backup/rst-copilot     # writes gateway-state-<timestamp>.tar.gz, keeps 30 days

copilot.db runs in WAL mode; the script archives the whole directory, so copilot.db-wal comes along. For a consistent single-file copy:

docker exec rst-qradar-ai-copilot-gateway python -c "import sqlite3;s=sqlite3.connect('/app/state/copilot.db');d=sqlite3.connect('/app/state/copilot-snapshot.db');s.backup(d)"

Suggested cron, daily at 02:00:

0 2 * * * cd /opt/rst-copilot && bash scripts/backup.sh /backup/rst-copilot >> /var/log/rst-backup.log 2>&1

Restore:

bash scripts/restore.sh /backup/rst-copilot/gateway-state-XXXX.tar.gz
docker compose -f docker-compose.prod.yml restart gateway

Accounts

docker exec rst-qradar-ai-copilot-userdb pg_dump -U rst rst_users > /backup/rst-copilot/users-$(date +%F).sql
# restore
docker exec -i rst-qradar-ai-copilot-userdb psql -U rst rst_users < users-XXXX.sql

Losing this volume does not stop the deployment: the gateway recreates the table and seeds the first admin from .env, but every other account is gone.

Retention

Inside copilot.db, audit follows RST_AUDIT_RETENTION_DAYS (default 180), investigation records RST_ANALYSIS_TTL_DAYS (default 30), conversations RST_CONVERSATION_TTL_DAYS (default 7). Keep audit for at least 180 days; for longer, raise the value and keep enough backup archives.

Restore drill

Rehearse at least once before go-live: restore.sh on a test host, then confirm the licence is valid, audit and investigation records are complete, and the Offenses page shows the dispositions from before. Restoring to a different host changes the fingerprint, so the licence has to be re-activated; for an online licence, "Deactivate this licence" on the old host first.