Making scheduled backups¶
You can automate the backup process with scheduled backups. You define a schedule and the Operator runs backups automatically according to it. This provides reliability and efficiency to your backups strategy and ensures your data is timely and regularly backed up with no gaps.
To configure scheduled backups, modify the backups
section of the deploy/cr.yaml Custom Resource manifest. Specify the following configuration:
backup.enabled
- set totrue
,backup.storages
subsection - define at least one configured storage.-
Configure the
backup.tasks
subsection:name
- specify a backup name. You will need this name when you restore from this backup.schedule
- specify the desired backup schedule in crontab format ).enabled
- set this key totrue
. This enables making the<backup name>
backup along with the specified schedule.storageName
- specify the name of your already configured storage.keep
- define the number of backups to keep in the storage. This key is optional. It applies to base incremental backups but is ignored for increments.type
- specify what type of backup to make. If you leave it empty, the Operator makes a logical backup by default.
Note that the
percona.com/delete-backup
finalizer applies for an incremental base backup but is ignored for increments. This means that when an incremental base backup is deleted, PBM also deletes all increments that derived from it from the backup storage. There is the limitation that the Backup resource for the base incremental backup is deleted but the Backup resources for increments remain in the Operator. This is because the Operator doesn’t control their deletion outsourcing this task to PBM. This limitation will be fixed in future releases.
Examples
This example shows how to set up backups to run every Saturday night and store them in Amazon S3:
...
backup:
enabled: true
storages:
s3-us-west:
type: s3
s3:
bucket: S3-BACKUP-BUCKET-NAME-HERE
region: us-west-2
credentialsSecret: my-cluster-name-backup-s3
tasks:
- name: "sat-night-backup"
enabled: true
schedule: "0 0 * * 6"
keep: 3
type: logical
storageName: s3-us-west
...
This example shows how to set up backups to run every Saturday night and store them in Amazon S3:
...
backup:
enabled: true
storages:
s3-us-west:
type: s3
s3:
bucket: S3-BACKUP-BUCKET-NAME-HERE
region: us-west-2
credentialsSecret: my-cluster-name-backup-s3
tasks:
- name: "sat-night-backup"
enabled: true
schedule: "0 0 * * 6"
keep: 3
type: physical
storageName: s3-us-west
...
To run incremental backups, consider the following:
- You must use the same storage for the base backup and subsequent incremental ones
- The
percona.com/delete-backup
finalizer and the.spec.backup.tasks.[].keep
option are is considered for incremental base backup but are ignored for increments. This means that when a base backup is deleted, PBM deletes all increments that derive from it.
There is the limitation that the Backup resource for the base incremental backup is deleted but the Backup resources for increments remain in the Operator. This is because the Operator doesn’t control their deletion outsourcing this task to PBM. This limitation will be fixed in future releases.
This example shows how to set up incremental base backups to run every Sunday at 5 a.m and subsequent incremental backups every night at 1:00 a.m. and store them in Amazon S3:
...
backup:
enabled: true
storages:
s3-us-west:
type: s3
s3:
bucket: S3-BACKUP-BUCKET-NAME-HERE
region: us-west-2
credentialsSecret: my-cluster-name-backup-s3
tasks:
- name: weekly-s3-us-west-incremental
enabled: true
schedule: "0 1 * * *"
type: incremental
storageName: s3-us-west
compressionType: gzip
compressionLevel: 6
- name: weekly-s3-us-west-incremental-base
enabled: true
schedule: "0 5 * * 0"
type: incremental-base
storageName: s3-us-west
compressionType: gzip
compressionLevel: 6
...
Restore to a new Kubernetes environment¶
To restore from a backup to a new Kubernetes-based environment, you must create a Secrets object there with the same user passwords as in the original cluster.
Find the Secrets name object on the source cluster in the spec.secrets
key in the `deploy/cr.yaml. Use this name to recreate the Secrets on the target cluster.
Find more details about secrets in System Users.