Backup and restore — Nistor Docs

All of Nistor's state is in one PostgreSQL database on Cloud SQL: the catalog, rules, incidents, users and the release log. The services hold no state of their own. Backing up Nistor means backing up that database.

What the root configures#

The core module creates the Cloud SQL instance (<db_instance_name>-<environment>, PostgreSQL 17 by default) with:

Automated backups every day, starting at 03:00 UTC, stored in the instance's region.
The 7 most recent backups kept. Older ones are deleted by Cloud SQL.
Deletion protection on: the core module's enable_deletion_protection defaults to true, and the root keeps that.

Point-in-time recovery (PITR) is not turned on: the core module's backup settings leave it off, and the root has no input for it. You restore to the time of a daily or an on-demand backup, not to an arbitrary moment.

Backups are of the database only. The services, images and Terraform state are rebuilt from your deployment repository and the release images. Configuration you keep as files (rules, alert policies, contracts) is in your own repository and can be synced again with the CLI.

Important

Rolling back a release (going back to the previous images) does not roll back the database. A migration that has run stays applied. Take an on-demand backup before every upgrade (see Upgrading):

gcloud sql backups create --instance=<instance> --project=<project> --description="before v<version>"

Restore#

Stop writes. Scale the backend, scheduler, jobs and compiler to zero, or put the environment behind maintenance, so that nothing writes while you restore.

Pick the backup.

gcloud sql backups list --instance=<instance> --project=<project>

Restore into a new instance (recommended), so that the damaged one stays available for inspection. Create the target instance first, with the same version and tier, then:
```
gcloud sql backups restore <backup id> \
  --backup-instance=<instance> \
  --restore-instance=<new instance> \
  --project=<project>
```
Restoring onto the original instance (--restore-instance=<instance>) overwrites everything in it.
Point the services at the restored instance. With the reference root, the instance name comes from db_instance_name and the environment. Either restore onto the original instance, or adopt the new instance into your Terraform state, then plan and apply.
Run the migrate job (output migrate_job_name). On a backup taken at the same release it applies nothing. On an older backup it brings the schema up to the running release.
```
gcloud run jobs execute <migrate job name> --region=<region> --project=<project> --wait
```
Start the services again, then check them as in Install on GCP.