Skip to content

Rate this page
Thanks for your feedback
Thank you! The feedback has been submitted.

Get free database assistance or contact our experts for personalized support.

About backups

Backing up your database protects your data from loss and corruption, helps ensure business continuity, and lets you quickly recover if something goes wrong.

How backups work

The Operator stores your MySQL backups outside the Kubernetes cluster on cloud storage. You can use:

image

The Operator creates physical backups using Percona XtraBackup . Here’s how it works:

  1. Each database Pod includes a sidecar container called xtrabackup that runs an HTTP server.
  2. When you create a backup, the Operator creates a Job that sends an HTTP request to the backup source Pod.
  3. The xtrabackup container receives the request and starts the backup process.
  4. Backups are streamed to storage; the Operator does not keep a separate local copy of the backup on disk.

The following diagram outlines this workflow:

image

Backup types

You can make the following types of physical backups:

  • Full backup - contains full data set
  • An incremental backup - contains only the changes that occurred since the previous backup. To learn more, read Incremental backups.

Configuring backups

You configure backups in the backup section of your deploy/cr.yaml file. This section includes:

Backup runs

You can create backups in two ways:

  • Scheduled backups: Configure these in your deploy/cr.yaml file. The Operator runs them automatically at the times you specify.
  • On-demand backups: Create these manually whenever you need them. You configure them in the deploy/backup/backup.yaml file.

Point-in-time recovery

Starting with Operator 1.1.0, you can combine a base backup with archived binary logs to restore to a specific GTID or timestamp. That flow uses a binlog server and object storage alongside your normal backup configuration.


Last update: April 17, 2026
Created: April 17, 2026