PVC Provisioning, Volume Snapshot, and Restore

VCF 9.0Intermediatevcap-advanced⏱ 135 min

Objectives

Create PVC-backed stateful application (PostgreSQL); snapshot; restore from backup.

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for Advanced VCF 9.0 VKS (vSphere Kubernetes Service)

Tasks

Task 1 PVC Provisioning, Volume Snapshot, and Restore

Create PVC-backed stateful application (PostgreSQL); snapshot; restore from backup.

Step 1

Deploy PostgreSQL StatefulSet with PVC using vsan-default StorageClass.

Step 2

Create database: kubectl exec -it postgres-0 -- psql -c "CREATE TABLE test (id INT, data TEXT);"

Step 3

Insert test data: INSERT INTO test VALUES (1, 'production-critical-data');

Step 4

Create VolumeSnapshot: kubectl apply -f pg-snapshot.yaml

Step 5

Verify snapshot created in vSAN: vsan-cli snapshot list | grep postgres

Step 6

Simulate disaster: kubectl delete pvc postgres-data-postgres-0

Step 7

Restore from snapshot: Create new PVC with dataSource pointing to snapshot.

Step 8

Verify data restored: kubectl exec -it postgres-0 -- psql -c "SELECT * FROM test;" Confirm original data present.

Step 9

Document RPO/RTO: Snapshot creation time, restore duration, impact on application SLA.

Validation Gate

Check: Verify lab completion

Expected: Lab exercise completed successfully

Common Errors

PVC bound to wrong storage class with inappropriate performance characteristics

Fix: If multiple storage classes exist (vsan-default, vsan-performance, vsan-archive), and PVCs don't specify storageClassName, they bind to the default class which may not match workload needs. Always specify storageClassName explicitly in PVC manifests. Verify: kubectl get pvc shows correct storage class and bound status.

Volume snapshot taken during active I/O causing inconsistent data

Fix: vSAN volume snapshots are crash-consistent, not application-consistent. For databases, quiesce the application before snapshot: run database flush/freeze command, take snapshot, then thaw. Without quiescing, the snapshot may contain partial transactions.

Restore from snapshot failing due to insufficient storage capacity

Fix: Restoring a volume from snapshot creates a new PV from the snapshot data. This requires available capacity equal to the snapshot size in the vSAN datastore. If capacity is tight, the restore fails. Check vSAN capacity before restore operations.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

Persistent storage design for Kubernetes on VCF shows full-stack understanding. VCDX panelists test storage class mapping to vSAN policies, snapshot consistency, and capacity planning.

⚠ Known Pitfalls (from Community KB)

Not specifying storageClassName in PVCs — pods get default storage class which may be wrong.

Taking database snapshots without quiescing — crash-consistent snapshots may contain incomplete transactions.

Mark complete