Restoring from a backup

Restoring reverses the backup procedure: load the SQL dump back into the database and put the uploaded files back in place. There is no in-app restore — this is done at the infrastructure level.

1. Restore the database

Make sure the database container is running, then stream the gzipped dump into the mariadb client inside the container:

gunzip -c /opt/summitpsa/backups/db-YYYYMMDD-HHMMSS.sql.gz \
  | sudo docker compose -f /opt/summitpsa/docker-compose.yml exec -T db \
    sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" "$MARIADB_DATABASE"'

This loads the dump into the existing database. If you are rebuilding from scratch, bring up the db service first so the database and credentials exist before importing.

2. Restore uploaded files

sudo tar xzf /opt/summitpsa/backups/uploads-YYYYMMDD-HHMMSS.tar.gz \
  -C /opt/summitpsa

3. Match the app version to the backup

The schema in your dump corresponds to whatever app version was running when it was taken. Bring up an app image whose schema matches the dump:

• Restoring into the same version the backup came from is the simplest path — the entrypoint's alembic upgrade head will be a no-op.
• Bringing up a newer image will auto-migrate the restored schema forward on boot.
• Do not bring up an older image against a newer dump — it will crash-loop. See Rolling back an update.

4. Bring up and verify

sudo docker compose -f /opt/summitpsa/docker-compose.yml up -d app
sudo docker compose -f /opt/summitpsa/docker-compose.yml logs --tail=40 app
sudo docker compose -f /opt/summitpsa/docker-compose.yml exec -T app alembic current

Confirm you can log in and that recent tickets, invoices, and attachments are present.