Backup and restore
Backup And Restore Overview
Bloodraven backs up MySQL with mysqlsh util.dumpInstance() and restores with util.loadDump(). Backups are configured on MysqlFailoverGroup.spec.backup; one-off backup runs use MysqlBackup.
Choose a storage backend
| Backend | Best for | Avoid when |
|---|---|---|
| S3 | Off-cluster durable backups, cross-cluster restore, production DR | You cannot grant object-store credentials safely |
| PVC | Local labs, isolated environments, short-term staging | You need disaster recovery after cluster or storage loss |
| PITR | Lower RPO between full dumps | You cannot operate binlog archive storage and verification |
Workflow
- Configure a backup profile on the failover group.
- Add a schedule for recurring backups.
- Trigger one manual
MysqlBackupbefore go-live. - Verify the backup with
MysqlBackupVerification. - Document the restore path and test it on a non-production group.
Backup source eligibility
Bloodraven prefers a healthy replica within the configured backup lag
threshold and falls back to the confirmed active primary. A healthy
dr-only follower remains eligible. A read-only site is never selected as
an automatic backup source, and setting sourceSiteOverride or
kubectl bloodraven backup --source-site to a reader is rejected. This keeps
application read pools and backup load separate; reclassify the site only if
you intend to change its operational role.
Start here
- S3 Backups for object storage.
- PVC Backups for local persistent volumes.
- Backup And Restore Reference for full behavior, retention, PITR, and restore safety.
- Backup Encryption for application-level encryption.
- Backup Verification for proving recoverability.
Restore safety
spec.initFromBackup initializes a new failover group from a backup. In-place restore controls are destructive. Confirm target namespace, failover group name, source backup, and DNS exposure before applying restore manifests.