just backup / restore / list-backupsPer-service backup + restore + listing. Backup type (
database/volume/workspace/config) declared in the manifest; the recipe picks the right snapshot mechanism automatically.
For the conceptual walk + the restore drill, see /pma/learn/05-backup-and-restore.
| Recipe | What it does |
|---|---|
just backup |
Backup every service whose manifest has backup.enabled: true |
just backup SERVICE |
Backup one service |
just backup all |
Same as just backup |
just backup --parallel |
Run service backups in parallel (faster but heavier I/O) |
just backup list |
Show recent backups for every service |
just backup clean [DAYS] |
Remove backups older than N days (default 30) |
Backup output goes to .asd/workspace/backups/<service>/<timestamp>/. The timestamp format is YYYYMMDD_HHMMSS.
For services with backup.type: database, the snapshot is dump.sql (postgres) or dump.sql.gz (mariadb/mysql).
For services with backup.type: volume, the snapshot is volume.tar.gz.
For services with backup.type: workspace, the snapshot includes both the database (if any) and the workspace dir.
| Recipe | What it does |
|---|---|
just restore SERVICE TIMESTAMP |
Restore one service from a specific backup |
just restore SERVICE latest |
Restore from the most recent backup |
just restore-all TIMESTAMP |
Multi-service restore in startup-priority order |
just restore SERVICE TIMESTAMP --dry-run |
Show what would happen, don't mutate |
Restore behaviour by backup type:
database → drop + recreate the database, load the dump.volume → stop container, untar the volume, chown to data_uid, restart.workspace → restore the workspace dir (and DB if present).config → replace the env-var slice from the backup.After the data is in place, restore walks fixes.post_restore.functions from the manifest. These are the per-service quirks (unlock migration tables, regenerate session secrets, chown data volumes for UID drift, drop stale OAuth clients).
| Recipe | What it does |
|---|---|
just list-backups [SERVICE] |
All / one service's backup history |
just backup-info SERVICE TIMESTAMP |
Metadata for one backup (size, contents, manifest snapshot) |
just backup-verify SERVICE TIMESTAMP |
Sanity-check the backup (dump parses, tar extracts) |
just disk |
Disk usage on the host (incl. backups) |
For prod, on-host backups aren't enough — your host could go.
asd data push (from the asd CLI) uploads a workspace snapshot to the asd org registry. To use it for backups:
# After taking local backups
just backup
# Push the whole workspace snapshot off-host
asd data push --label "backup-$(date -u +%Y%m%d)"
Pull on another machine:
asd data pull <label>
See /asd/internals/registry for the asd-side push/pull mechanics.
Alternative: rsync .asd/workspace/backups/ to S3 / B2 / another host. PMA doesn't bundle a cron for this — write your own per the off-host destination of your choice.
# In cron on the host (e.g. /etc/cron.d/pma-backup)
0 2 * * * pma cd /opt/asd-pma && just backup
0 3 * * * pma cd /opt/asd-pma && just backup clean 30 # rotate
# 1. Pick a service
SVC=redmine
# 2. Take a fresh backup so you have a known-good baseline
just backup $SVC
# 3. Note the timestamp
just list-backups $SVC | head -1
# 4. Restore the SECOND-most-recent backup (proves rotation works)
TS=$(just list-backups $SVC | sed -n '2p' | awk '{print $1}')
just restore $SVC $TS
# 5. Verify
just status $SVC
# Service should be back, no errors in logs
Practise this on a dev or test env — see /pma/learn/05-backup-and-restore for the full drill.
release-run takes per-service backups automatically in phase 1. You can replicate this manually before any risky operation:
just backup <svc> # snapshot
# ... do the risky thing ...
just restore <svc> $(just list-backups <svc> | head -1 | awk '{print $1}') # roll back if needed
/pma/learn/05-backup-and-restore — the restore drill walked end to end./pma/reference/manifest — backup.* and fixes.post_restore.* fields./pma/reference/cli/release — release-run takes backups in phase 1.