Backups · BaryoVM

baryovm stack add baryoclub --vm oracle --path /home/deploy/baryoclub-src/BaryoClub/deploy \
  --db-container deploy-postgres-1 --db-name baryoclub --env-file .env \
  --backup-dir /home/deploy/baryoclub-backups --keep 14

baryovm stack backup baryoclub      # pg_dump (custom format) + copy .env, prune to --keep
baryovm stack backups baryoclub     # list backups, newest first
baryovm stack restore baryoclub --yes                    # newest (REPLACES data)
baryovm stack restore baryoclub --file db-YYYY….dump --yes

If the project's .env is root-owned, the right posture for a file holding the database password, add --sudo, and that stack's docker and compose commands, its backup's dump and .env copy, and its release's builds, hooks and remote rsync all run through sudo -n. Without it compose fails with "permission denied" reading the file, even though Docker itself is reachable. Loosening the file to suit the tool would be the wrong trade. The backup script's own file handling (creating the backup directory, writing the dump, pruning) stays as the SSH user, so --backup-dir has to be a directory that user can write.

baryovm stack add baryodev --vm oracle --path /opt/baryo-cms --sudo \
  --db-container baryo-postgres --db-name barako_cms --env-file .env

Backup config flags on stack add: --db-container, --db-name, --db-user (default postgres), --env-file (relative to the project dir), --backup-dir (default ~/<name>-backups), --keep (default 14). Restore refuses without --yes.

Example: recreating the barakoCMS API and the barakoBrew console together is one command:

baryovm stack deploy barako --force-recreate --service api,console

Backups (pg_dump + config, over SSH)