canasta backup schedule

Manage scheduled backups

Synopsis

Manage recurring backup schedules. Scheduling is the same on both orchestrators: a crontab entry on the host where the instance runs — the local or remote host for Compose, the control-plane node for Kubernetes (the same host the instance's other commands run on). The entry runs canasta backup create -i <id> --tag scheduled on the schedule, which performs the backup the orchestrator-native way: a Compose container, or an in-cluster restic Job for Kubernetes. Output goes to backup.log in the instance directory; failures are visible there and via tail -F.

That host therefore needs the cron package (Debian: apt install cron) and a runnable canasta — the cron entry calls canasta backup create. canasta backup schedule set fails with guidance if either is missing on a remote / control-plane host. The schedule is also persisted to config/backup-schedule.yml, so it is captured by backups and re-materialized on restore.

For Kubernetes, the in-cluster backup Job runs a dump-databases init container (mariadb-dump for every DB on the configured MYSQL_HOST) followed by a restic container that snapshots the instance's PVCs. Both envFrom a canasta-<id>-backup-env Secret synced from the instance's .env, containing restic + cloud-backend credentials (RESTIC_*, AWS_*, B2_*, AZURE_*, GOOGLE_*, OS_*, ST_*) plus MYSQL_HOST / MYSQL_USER / MYSQL_PASSWORD. Find a failed run via kubectl get jobs -n canasta-<id> (status Failed) and kubectl logs -n canasta-<id> job/<name>.

Subcommands

This command requires a subcommand:

list — Show the backup schedule
remove — Remove a scheduled backup
set — Set a recurring backup schedule

Global flags

Flag	Shorthand	Description	Default	Required	Orchestrator
`--help`	`-h`	Show help message and exit			Both
`--verbose`	`-v`	Enable verbose output			Both