Kubernetes Stateful Migration with Backup and Restore

Use case

• Category: Kubernetes-to-Kubernetes migration
• State profile: Stateful workloads
• Approach: Backup and restore with planned downtime window

Mandatory prerequisites

• Data topology documented: Data stores, PVC mappings, and retention constraints are known.
• Backup tooling validated: Backup and restore process is tested in a non-production rehearsal.
• Storage compatibility confirmed: Target storage classes and performance profile are approved.
• Downtime governance approved: Business owners approved the migration window and fallback rules.

Map each source PVC to an offered target storage class and verify its reclaim policy, binding mode, and expansion behavior. These product properties do not establish backup-format compatibility or application-consistent recovery; prove both in the rehearsal.

From the STACKIT docsStorage classes › Storage classes in STACKIT Kubernetes clustersSource updated 19.08.2026 · copied 06.10.2026

From the Kubernetes docs:

“A StorageClass provides a way for administrators to describe the “classes” of storage they offer. Different classes might map to quality-of-service levels, or to back up policies, or to arbitrary policies determined by the cluster administrators. Kubernetes itself is unopinionated about what classes represent. This concept is sometimes called “profiles” in other storage systems.”

SKE offers the following different storage classes based on the performance classes provided by the IaaS layer (see Block Storage service plans):

NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
premium-perf0-stackit cinder.csi.openstack.org Delete Immediate true 33h
premium-perf1-stackit (default) cinder.csi.openstack.org Delete Immediate true 33h
premium-perf2-stackit cinder.csi.openstack.org Delete Immediate true 33h
premium-perf4-stackit cinder.csi.openstack.org Delete Immediate true 33h
premium-perf6-stackit cinder.csi.openstack.org Delete Immediate true 33h

A list of available storage classes in your Kubernetes cluster can be retrieved with the following command:

kubectl get storageclasses

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Not suitable when

• Downtime cannot be accepted: Business continuity requires zero interruption.
• No reproducible restore exists: Restore consistency cannot be verified ahead of cutover.

Implementation template

Phase 1: Prepare backup and target state

1. Freeze schema and release changes affecting data model.
2. Prepare target cluster resources and storage classes.
3. Run rehearsal backup and rehearsal restore.

Phase 2: Final backup and restore

1. Enter production freeze window and stop source writers.
2. Run final backup and transfer artifacts.
3. Restore into target cluster and run integrity checks.

Phase 3: Activate target and stabilize

1. Start target application components in controlled order.
2. Validate data integrity and business-critical operations.
3. Switch user traffic and monitor stabilization.

Validation checklist

• Restore completeness: Required datasets restored successfully.
• Integrity evidence: Record counts and domain checks pass.
• Performance baseline: Critical transactions meet threshold.
• Fallback readiness: Source reactivation path remains available until sign-off.