Cloning PersistentVolumeClaims Across Namespaces in Azure Red Hat OpenShift (ARO)

Copy persistent volume data from one OpenShift namespace to another on Azure Red Hat OpenShift (ARO) using the default managed-csi storage class (Azure Disk CSI).

This guide walks through a self-contained lab you can run without deploying a full application stack. Use it when you need to duplicate data into a new namespace for testing, migration, or recovery. For cluster-wide backup and restore to Azure Blob Storage, see Backup and Restore for ARO using OADP .

Overview

Cross-Namespace PVC Cloning Workflow

What works on ARO

On managed ARO, block volumes use the managed-csi storage class (Azure Disk CSI). How you copy PVC data depends on whether the source and target namespaces are the same.

Cross-namespace (this guide). When the source PVC and the new PVC are in different namespaces, use volume snapshot import: snapshot the source PVC, copy the Azure snapshotHandle from the cluster-scoped VolumeSnapshotContent, pre-provision import content in the target namespace, restore a PVC from a namespaced VolumeSnapshot, then mount it from a pod or workload. The diagram above and the steps below follow this pattern.

Same namespace. If both PVCs stay in one namespace, you do not need snapshot import. Use the OpenShift console Clone action, or create a new PVC with dataSource: PersistentVolumeClaim pointing at the source claim.

Other cross-namespace options. For small volumes or one-off copies, file-level copy with tar and oc exec works without snapshots. The Kubernetes CrossNamespaceVolumeDataSource feature is alpha and is not enabled on managed ARO.

Patterns to avoid. Do not restore a cross-namespace clone by setting dataSource: VolumeSnapshotContent on the target PVC (Azure Disk CSI provisions an empty disk). Do not create a bridge VolumeSnapshot that references the source namespace’s dynamic VolumeSnapshotContent (the driver expects pre-provisioned content).

Azure Disk (managed-csi) requirements

• Storage class managed-csi uses WaitForFirstConsumer: PVC stays Pending until a pod mounts it.
• Source volume must be attached to a running pod when the snapshot is taken.
• Run sync on the source pod before snapshotting so data is flushed to disk.
• Restored PVC size must be ≥ snapshot restore size.
• On Azure Disk CSI, restore PVC must use dataSource: VolumeSnapshot (namespaced), not VolumeSnapshotContent directly.

Prerequisites

Before starting, ensure you have:

• oc logged in to an ARO cluster
• Cluster admin or sufficient RBAC to create snapshots and PVCs in both namespaces
• Azure Disk CSI snapshots enabled on the cluster
• For cloning an existing workload, a source PVC that is bound and mounted by a running pod

Confirm prerequisites

Confirm the CLI can reach the cluster:

Confirm the default block storage class:

Expected output (values may vary):

Confirm a VolumeSnapshotClass exists for Azure Disk:

Expected output:

If no VolumeSnapshotClass exists, check your OpenShift version and the Azure Disk CSI operator in openshift-cluster-csi-drivers.

Set environment variables

Customize these for your clone:

Step 1: Create namespaces

Expected output:

Step 2: Create source PVC and write test data

Create the source PVC:

Create a writer pod that mounts the PVC and writes a test file:

Wait for the pod to be ready and confirm the PVC is bound:

Expected output:

Read the test file and flush data to disk before snapshotting:

Expected output:

Step 3: Take a VolumeSnapshot

Wait until the snapshot is ready:

Expected output:

Step 4: Get the Azure snapshot handle

Expected output:

Step 5: Import snapshot into the target namespace

Do not point a PVC directly at the source VolumeSnapshotContent. Azure Disk CSI ignores it and provisions an empty disk (only lost+found).

Do not create a bridge VolumeSnapshot that references the dynamically provisioned source content. That fails with:

Instead, create a new pre-provisioned VolumeSnapshotContent in the target namespace using the Azure snapshotHandle, then a bridge VolumeSnapshot, then restore the PVC from that local VolumeSnapshot.

Pre-provisioned import content:

Bridge VolumeSnapshot in the target namespace:

Wait until the imported snapshot is ready:

Expected output:

Step 6: Restore PVC from imported VolumeSnapshot

The PVC may show Pending until a pod mounts it (WaitForFirstConsumer):

Expected output before a pod mounts:

Step 7: Mount restored PVC and verify data

Expected output:

Success: the testfile.txt content matches what the source pod wrote. You should see testfile.txt and ready, not only lost+found.

Step 8: Deploy your workload

Apply the restored PVC before deploying Helm or other installers. If the installer creates the PVC first (without dataSource), you get an empty disk that mounts correctly but has no data.

For Helm charts, use the chart-specific key for an existing claim (for example volume.existingClaim or persistence.claimNameOverwrite). Confirm the workload references ${TARGET_PVC}, not a release-generated PVC name.

Verify the correct PVC is mounted and data is present inside the pod before declaring success:

Step 9: Cleanup

Deleting only the lab namespaces is not enough before a second run. VolumeSnapshotContent is cluster-scoped and survives oc delete namespace.

Second run fails: snapshotHandle is immutable

If a second lab run fails during import with:

Cause: Each run creates a new Azure disk snapshot with a new snapshotHandle. Reusing a fixed import object name leaves the old handle in place. A subsequent oc apply tries to update spec.source.snapshotHandle, which Kubernetes does not allow.

Fix: Delete the leftover import objects, then re-run from Step 3:

Same-namespace clone (optional)

When source and target PVCs are in the same namespace, the OpenShift console Clone action or a PVC dataSource works:

Deploy a pod that mounts my-pvc-clone to satisfy WaitForFirstConsumer.

Alternative: file-level copy

For small volumes or when snapshot restore is problematic:

1. Scale down the source application.
2. Create an empty PVC in the target namespace (no dataSource).
3. Run a writer pod on the source PVC and a reader pod on the target PVC.
4. Stream data:

Related guides

• Backup and Restore for ARO using OADP (cluster wide backup to Azure Blob Storage and disaster recovery)
• Azure Disk CSI clone example