canasta backup schedule

Manage scheduled backups

Synopsis

Manage recurring backup schedules. The implementation differs by orchestrator:

- Compose** instances use a host crontab entry that runs

canasta backup create -i <id> --tag scheduled on the schedule. Output goes to backup.log in the instance directory; failures are visible there and via tail -F. Requires the cron package on the host (Debian: apt install cron).

- Kubernetes** instances use a CronJob named

canasta-backup-<id> in the instance namespace. The Job pod 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 containers envFrom a canasta-<id>-backup-env Secret that's synced from the instance's .env and contains restic + cloud-backend credentials (RESTIC_*, AWS_*, B2_*, AZURE_*, GOOGLE_*, OS_*, ST_*) plus MYSQL_HOST / MYSQL_USER / MYSQL_PASSWORD. The CronJob keeps the last 3 successful and 7 failed Jobs for post-mortem.

When a scheduled K8s backup fails, the operator finds it via kubectl get jobs -n canasta-<id> (status Failed) and kubectl logs -n canasta-<id> job/<name> for the dump or restic error. Watch out for the failed-history limit cycling old failures off the cluster after seven runs.

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