Upgrade, rollback and backup

You can upgrade the gateway three ways. A delivery archive works for every deployment, online update needs an online license, and a manual image switch gives you step-by-step control. License state lives in state/ and the gateway_state volume, not in the image.

Upgrade to 1.2.22

Upgrade to 1.2.22 or later. From 1.2.22, activation sends the license token as proof that you hold the license. The license server will later require it, and from then on 1.2.21 and earlier fail on a new installation or a re-activation.

• 1.2.21: use the online update.
• 1.2.20 or earlier: upgrade once with the new archive as in the next section; the install command installs the latest version directly.

Also fixed in this release: after a manual upgrade (deploy.sh), rst-update.sh --rollback goes back exactly one version, and rst-update.sh --prune-old removes images left under the old product name. The UI is unchanged.

Upgrade from 1.2.20 or earlier to 1.2.21

From 1.2.21 the release files, images and containers use the product name RST-AI-Copilot-for-Elastic, and the GitHub repository is Reallysec/RST-AI-Copilot-for-Elastic. A gateway on 1.2.20 or earlier cannot update online to 1.2.21. Upgrade once with the new archive, either way:

• Run the install command again:

  curl -fsSL https://github.com/Reallysec/RST-AI-Copilot-for-Elastic/releases/latest/download/install.sh | sudo bash

• Unpack the new archive into the existing install directory and run ./deploy.sh there, as in Upgrade with a delivery archive.

Keep the existing install directory. Older installs use /opt/rst-elastic-ai-copilot, and the install command finds it by itself. Data, settings and activation are kept. Once on 1.2.21, online updates work again. Container names in commands change to rst-ai-copilot-for-elastic-*, for example docker exec rst-ai-copilot-for-elastic-gateway.

Upgrade with a delivery archive

Steps

1. Unpack the new archive into the existing install directory:

   tar xzf RST-AI-Copilot-for-Elastic-<version>.tar.gz --strip-components=1 -C <install-dir>

2. In the install directory, run sudo ./deploy.sh.

3. At the prompt to keep the existing .env, answer Y. The default is N, which overwrites .env.

4. At the prompt to upgrade to <version>, answer Y.

Scripts and compose files are replaced; .env and state/ are kept. The script loads every image bundle in the directory, switches GATEWAY_IMAGE_TAG to the newest, recreates the containers with --force-recreate, and waits for healthy. If an image the compose file needs is missing, the script lists it before start-up.

Confirm the running image:

docker inspect rst-ai-copilot-for-elastic-gateway --format '{{.Config.Image}}'

Online update

Prerequisites

• An online license that has completed one heartbeat.
• The gateway runs 1.2.21 or later. For 1.2.20 or earlier, see Upgrade from 1.2.20 or earlier to 1.2.21.

Steps

1. In Settings > Version and updates, select Download and stage.

2. On the host, in the install directory, run:

   sudo ./deploy/rst-update.sh

The gateway verifies the signature and stores the image in ./release/staging. rst-update.sh loads it, switches GATEWAY_IMAGE_TAG and probes health: three consecutive passing checks count as success, and if that does not happen within 120 seconds it rolls back.

To return to the previous version yourself, run sudo ./deploy/rst-update.sh --rollback. With an overlay, set COMPOSE_FILE to a colon-separated list first, for example docker-compose.prod.yml:my-overlay.yml.

Switch the image manually

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

Roll back

Set GATEWAY_IMAGE_TAG back to the previous version and restart:

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

Backup scope

Back up gateway state

bash scripts/backup.sh /backup/rst-copilot

The script writes gateway-state-<timestamp>.tar.gz and deletes backups older than 30 days. A daily cron at 02:00:

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

To restore:

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

Back up the account table

docker exec rst-ai-copilot-for-elastic-userdb pg_dump -U rst rst_users > /backup/rst-copilot/users-$(date +%F).sql

To restore:

docker exec -i rst-ai-copilot-for-elastic-userdb psql -U rst rst_users < users-<date>.sql

If the userdb_data volume is lost, the deployment still starts. The gateway recreates the table and re-seeds the first administrator from .env; every other account is lost.

Back up Elasticsearch indices

Add .rst_copilot_* to the index list of your existing snapshot:

PUT /_snapshot/<repo>/snap-<date>?wait_for_completion=true
{ "indices": ".rst_copilot_*", "include_global_state": false }

Keep audit logs for at least 180 days.

Restore drill

Before go-live, run restore.sh and an Elasticsearch _restore on a test host. The gateway should start with the license Valid and the audit and knowledge-base data intact.

Restoring onto a different host changes the fingerprint and requires activation again. Deactivate an online license on the old host first.