# Backups and upgrades

## Backups

Admin → System & settings → **Backups** creates database backups with `pg_dump -Fc` as a background job (`backup.pg_dump`), lists them, downloads them and deletes them. Files are written to `PELTY_BACKUP_DIR` (default `./backups`); file names are generated by the server.

| Variable | Default | Description |
|---|---|---|
| `PELTY_BACKUP_DIR` | `"backups"` | Where database backups are written (default `backups`). |
| `PELTY_PG_DUMP` | `"pg_dump"` | `pg_dump` binary used for backups (default `pg_dump` on PATH). |

These are PostgreSQL custom-format dumps. Restore one into an empty database with `pg_restore`, for example:

```bash
pg_restore --clean --if-exists --no-owner -d "$DATABASE_URL" peltycms-backup.dump
```

Keep copies off the server too, and also back up `PELTY_ENCRYPTION_KEY`: without it the encrypted secrets in the dump cannot be read. Uploaded addons and themes live in `PELTY_ADDONS_DIR` and `PELTY_THEMES_DIR`; back those up if you added your own.

## Upgrades

Once released, PeltyCMS is planned to ship as a binary or container image, so upgrading will be a redeploy:

- Take a backup.
- Replace the binary or pull the new image.
- Restart. `pelty-server serve` applies new database migrations on start (`pelty-server migrate` runs them on their own).

The daily `system.update_check` job compares the running version with the latest release and shows staff a banner with the release notes link. The release feed URL and on/off switch are stored under `update_check`. The [Database migrations](developers/migrations.md) page lists every migration.

## Health

Admin → System & settings → **System health** runs the system health checks. `/healthz` answers `ok` for load balancers and container health checks.