Backup and restore #

A useful backup must make it possible to restore a coherent state of the business, documents and structuring secrets.

Elements to protect #

• PostgreSQL database;
• Redis data if their recovery is required;
• volume isms_document_files or S3/MinIO bucket;
• volume jwt_keys ;
• configuration and secrets kept outside Git;
• exact version of the code and images deployed.

Composer and npm dependencies can be rebuilt; they do not replace data backup.

Prepare a backup #

Set RPO, RTO, retention, encryption, offsite location and responsible. Check available space and log application versions and migrations.

PostgreSQL logical example to adapt to your environment:

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc > riskpilot.dump

Do not place a password in the device history. Then back up documentary volumes and keys with a tool that preserves permissions and integrity.

Check #

A successful order is not enough. Control the size, footprint, encryption, readability of the catalog and presence of documents. Copy the backup out of the main server according to your policy.

Restore during exercise #

1. Create an isolated and compatible instance.
2. Restore secrets and keys without exposing them.
3. Restore PostgreSQL before making the application accessible.
4. Restore documents and, if necessary, Redis.
5. Start services without user traffic.
6. Only apply migrations compatible with the restored version.
7. Check /api/health, connection, tenants, ACL, downloads and exports.
8. Record duration, gaps and improvement actions.

Points of vigilance #

Restoring with another APP_SECRET may make encrypted secrets unreadable. Different JWT keys invalidate sessions, which may be desired after an incident but must be anticipated. The database and files must come from a consistent time point.

After disaster #

Before failover, confirm integrity, change suspected secrets, revoke sessions if necessary, and document the decision. Never test a restore on top of the single production instance.

Isolated restore verification #

After scripts/backup.sh, regularly run ./scripts/restore-verify.sh /srv/backups/riskpilot/<timestamp>. It starts an unexposed ephemeral PostgreSQL instance, imports the dump with stop-on-first-error, verifies tables, and inspects the document archive and Redis file. The validation container is always removed. A backup should be declared usable only after this real restore succeeds.