Back Up and Restore GKE Persistent Volumes with Backup for GKE (2026)

Backup for GKE lets you protect your stateful workloads by backing up and restoring Persistent Volumes (PVs).

Let’s see it in action. Imagine we have a PostgreSQL database running on GKE. We want to back it up.

First, we need to install the Backup for GKE agent. This is usually done via a Helm chart.

helm install backup-for-gke backup-for-gke/backup-for-gke \
  --namespace backup-for-gke \
  --create-namespace \
  --set clusterName=my-gke-cluster \
  --set location=us-central1

This deploys the necessary controllers and agents into your cluster. The clusterName and location are crucial for Backup for GKE to identify your cluster.

Next, we define a BackupPlan. This is where we specify what to back up and when.

apiVersion: backupforgke.gcp.cloud.google.com/v1
kind: BackupPlan
metadata:
  name: my-postgres-backup-plan
  namespace: default # The namespace where your PostgreSQL is running
spec:
  cluster: projects/my-gcp-project/locations/us-central1/clusters/my-gke-cluster
  backupConfig:
    includeVolumePatterns:
      - "postgres-data-*" # Back up PVs with names starting with "postgres-data-"
    includeNamespaces:
      names:
        - "default" # Only back up resources in the "default" namespace
    retentionPolicy:
      backupRetainDays: 7
      backupDeleteLockDays: 7
    backupSchedule:
      cronSchedule: "0 2 * * *" # Daily at 2 AM
  target:
    gcsBuckets:
      - bucketName: gs://my-gke-backups/postgres

This BackupPlan tells Backup for GKE to:

• Target my-gke-cluster in us-central1.
• Include any Persistent Volumes whose names start with postgres-data-.
• Only back up resources within the default namespace.
• Keep backups for 7 days, with a 7-day lock before deletion.
• Run the backup every day at 2 AM.
• Store the backups in the GCS bucket gs://my-gke-backups/postgres.

Once the BackupPlan is applied, Backup for GKE will automatically create Backup resources based on the schedule. You can view these using kubectl get backups -n default.

Now, let’s say your PostgreSQL instance experiences data loss or corruption. You need to restore it.

First, you create a Restore resource. This references the Backup you want to restore from.

apiVersion: backupforgke.gcp.cloud.google.com/v1
kind: Restore
metadata:
  name: my-postgres-restore
  namespace: default # Restore to the same namespace
spec:
  backup: projects/my-gcp-project/locations/us-central1/backups/my-postgres-backup-plan/backups/a-specific-backup-id # Replace with your actual backup ID
  cluster: projects/my-gcp-project/locations/us-central1/clusters/my-gke-cluster
  volumeDataRestorePolicy:
    allNamespaces: false # Only restore specified volumes
  # If you want to restore to a different namespace or with different PV names,
  # you'd specify volumeDataRestoreConfig here.

Applying this Restore resource triggers the restore process. Backup for GKE will provision new Persistent Volumes and copy the data from the specified backup.

The most surprising thing about Backup for GKE is how it handles volume restoration. It doesn’t just snapshot the raw disk; it understands the underlying storage and can orchestrate the creation of new PVs and the data transfer. This means you can restore to a different cluster or even to a different storage class if your Restore configuration specifies it, though direct volume data restoration often implies restoring to the same cluster to maintain consistency with application deployments.

The volumeDataRestorePolicy is key. Setting allNamespaces: true would attempt to restore all volumes found in the backup, regardless of namespace, which is usually not what you want for a specific application restore. For targeted restores, you’d typically ensure your BackupPlan was specific enough, or use volumeDataRestoreConfig in the Restore resource to map specific PVs or namespaces.

When you restore, Backup for GKE creates new PersistentVolumeClaims (PVCs) and PersistentVolumes (PVs) that mirror the state of the backed-up volumes. Your application’s Deployment or StatefulSet, if configured to select PVCs by label or name, will then automatically attach to these newly created volumes.

The next concept you’ll encounter is managing multiple backup plans for different applications and configuring more advanced restore scenarios, like restoring to a different GKE cluster.