Backup and Upgrade

What to back up

Item	Why
The PostgreSQL database	Holds everything: findings, review decisions, suppressions, rules and their version history, scan configurations, audit events, and the encrypted Jira and SMTP credentials.
JIRA_CREDENTIAL_ENCRYPTION_KEY	Without it the stored Jira and SMTP credentials in a restored database cannot be decrypted.
FINDING_FINGERPRINT_HMAC_SECRET	Without it, findings restored from backup no longer match what the next scan produces.
Your license file	Re-uploading is trivial, but keep the file so you are not waiting on a re-issue during a restore.

The container itself is stateless. There is no volume to back up and no file on disk that needs preserving - a lost container is replaced by starting the image again with the same environment.

pg_dump --format=custom --file=riskscanner-$(date +%F).dump riskscanner

Restoring

1. Restore the database into an empty PostgreSQL database.
2. Start the image with the same two secrets the backup was taken with.
3. Sign in and confirm on Administration -> Jira Connection that Test connection still passes. A failure here almost always means the encryption key does not match the backup.

Upgrading

Upgrades are a container replacement. Schema changes are applied automatically by Flyway on startup, forward-only; there is no separate migration command and no downgrade path.

1. Back up the database. This is the only rollback you have.

2. Make sure no scan is running. A scan that is interrupted mid-run can be resumed afterwards, but finishing first keeps the picture simple.

3. Pull the new image and restart the container with unchanged environment variables:

   docker pull arcsoftklg/sensitive-data-scanner:latest
   docker stop sensitive-data-scanner && docker rm sensitive-data-scanner
   # start again with the same run command

4. Watch the logs until the Flyway migration finishes and GET /actuator/health reports UP.

Your license, rules, findings, and configurations all live in the database and survive the upgrade. Built-in detection rules may gain new versions with a new release; existing custom rules and their version history are untouched.

The release that introduces versioned v2 finding fingerprints intentionally does not guess new identities from old findings: raw matched values were never stored, so an exact conversion is impossible. The first confirming scan creates new v2 identities; legacy findings remain as history until retention removes them, and review or suppression state is not copied automatically to a possibly different secret.

Rolling back

Flyway migrations are forward-only and clean is disabled. Downgrading to an older image against a newer schema is not supported - roll back by restoring the database backup you took in step 1 and starting the old image against it.

Rolling upgrades with more than one instance

If you are upgrading from a release that does not yet write scan heartbeats, wait for every running scan to finish before starting the first new instance. Older instances cannot report that their in-flight scans are still alive, so a heartbeat-capable instance would otherwise treat those runs as orphaned.

Once every instance runs a heartbeat-capable release, scheduling coordinates through the database (see Running more than one instance), and rolling restarts are safe for scans executing on instances that stay up. A scan that was executing on the instance you replace is the exception: it has nowhere left to run, and is marked failed within about 90 seconds so you can resume it on the new instance.

The new instance also applies its migrations as soon as it starts, so old and new instances briefly share a schema; keep the overlap short.