Of the eleven VCF 9 estates I have been inside this year, nine had Velero running on at least one VKS cluster. Three had ever completed a restore. That gap is not laziness. Installing Velero produces a satisfying green pod and a BackupStorageLocation that reports Available, and both of those are true statements about connectivity to a bucket rather than statements about your data being recoverable. Objective 4.13 is written by people who know the difference, which is why the verb in it is implement rather than install.

Data protection vocabulary for objective 4.13

Broadcom documents three ways for Velero to protect the data inside a persistent volume on a VKS cluster, and candidates routinely collapse them into one. They are not one. They differ in where the copy lands, how consistent it is, and whether the copy survives the loss of the datastore that holds the original. Pick the wrong one for a described scenario and every downstream answer in that item is wrong too.

Velero itself says CSI snapshot data movement should be preferred whenever it is available, because file system backup reads from a live volume and therefore never captures a single instant. On a vSAN backed VKS cluster it is always available, so file system backup on this estate is a fallback for a specific volume type rather than a strategy. That single sentence answers a surprising share of what objective 4.13 can ask.

Two things in that chart matter for design and both surprise people. First, restore is faster than backup on this estate, because a restore streams into a freshly provisioned volume while a backup has to snapshot, provision an intermediate claim, mount it and only then start reading. Second, the file system path costs roughly three times the data movement path on identical data. Anyone who reaches for file system backup because it sounds simpler is buying a slower and less consistent copy for no gain.

Prerequisites that decide whether a backup can even start

Last Part we put an application in front of users with an ingress controller and a private registry. This Part we take the same estate and remove the namespace on purpose. Before that is a defensible thing to do, four preflight facts have to be true, and every one of them was decided upstream of the VKS cluster you are logged into.

Read that last error rather than skipping it. It is the expected state before the server side exists, and it also tells you the CLI version you must match when you choose a package version. A client at 1.16.2 talking to a server at 1.17.0 is not a supported combination and it fails in ways that look like bucket problems.

Step by step, package repository to a verified restore

Step one is a values file, and it is where most installs go wrong. Velero needs a bucket, a region, path style addressing for MinIO, credentials, and if your object store presents a certificate from a private authority, that authority inline. Credentials never belong in a repository, so read them from the shell and render the file rather than typing secrets into YAML.

Check the exact repository path in the VKS Standard Packages release notes for your VKS build before you run step two. Broadcom changes the dated path on every packages release, and a stale path fetches an older bundle that quietly lacks the Velero version you were told to install [VERIFY the 3.3.0 path above against the release notes linked in References; I verified the pattern and a later dated path, not this exact string, on the day of writing].

A BackupStorageLocation reporting Available means Velero can list a bucket. It says nothing about whether a volume can be copied into it. Between those two facts sits a chain of six objects, and knowing the chain is the difference between reading a stalled backup in two minutes and staring at it for an afternoon.

flowchart TD
  A[velero backup create] --> B[Velero walks the namespace and finds a PVC]
  B --> C[CSI plugin creates VolumeSnapshot and VolumeSnapshotContent]
  C --> D[CSI plugin creates a DataUpload CR]
  D --> E{node agent claims the DataUpload}
  E -->|no pod on that node| F[Stalls in Accepted, cancelled after 30 minutes]
  E -->|claimed| G[Temporary PVC provisioned from the snapshot]
  G --> H{Bound within 30 minutes}
  H -->|no| F
  H -->|yes| I[Data mover pod runs Kopia and writes to the bucket]
  I --> J[DataUpload Completed, CSI snapshot deleted]

Note what the restore did to the volume identity. Capacity, access mode and StorageClass came back identical, but the underlying PersistentVolume has a new name, because Velero provisioned a new volume and streamed data into it. Anything in your estate that referenced the old volume handle, a monitoring dashboard keyed on volume id or a static PV mapping, is now pointing at nothing. That is a real day two consequence and it does not appear in any Velero output.

Verification, rollback, retention and a failure lookup

Rollback on a backup system is unusual to think about, because a failed backup does not damage anything. What can damage things is a failed restore into a live namespace. Velero has no existing resource policy by default, which means it skips objects that already exist and leaves you with a half restored namespace and no warning louder than a line in describe. Restore into a new namespace first and switch traffic afterwards.

Here is this Part's reference artifact, a symptom to owner lookup for Velero on VKS. Every row maps a string you will actually see to the object that owns the fix, and in three of six rows that object is not in the workload cluster at all.

Exam focus for objective 4.13

Objective checkpoint

Protection defaults worth committing to

My recommendation for this estate is narrow and I would defend it in a design review. Install Velero from the VKS standard packages repository rather than upstream, so version compatibility is Broadcom's problem rather than yours. Use CSI snapshot data movement everywhere, and treat file system backup as an exception you have to justify per volume. Back up one namespace per backup rather than the whole cluster, because Velero creates a backup repository per namespace anyway and a cluster wide backup sweeps in every package and package metadata object that the standard repository installed, which inflates item counts and hands you stale package objects on restore. Set item operation timeout to something you will actually wait for. And write down, next to the runbook, the row count or file hash that proves a restore worked, because a bound claim is not evidence.

What a clean result looks like: node-agent running on every worker node that can hold a volume, one BackupStorageLocation in phase Available marked default, a backup whose describe output names your claim under CSI Snapshots with Data Movement included, a DataUpload in Completed with a non zero bytes count, a restore into a mapped namespace that comes back with your row count intact, and a repository maintenance job that has run inside the last 24 hours. If any one of those six is missing you have a backup system that reports success.

Tonight, in your own lab: take one backup of a namespace that has data in it, then restore it with –namespace-mappings into a second namespace and compare a row count or a checksum across the two. It costs about five minutes on a small claim, it destroys nothing, and it is the single exercise that turns objective 4.13 from something you have read about into something you have done. Next Part moves from protecting a deployment to editing one, where a single YAML field decides whether a VKS cluster reconciles or wedges.

References

Product mechanics for VKS itself are covered in the VKS Series, and the registry that feeds these packages is covered in the Harbor guide. Readers arriving from a Tanzu Kubernetes Grid Integrated estate should start at the TKGI to VKS Series instead.

• Broadcom TechDocs, Backing Up and Restoring VKS Cluster Workloads
• Velero 1.16 documentation, CSI Snapshot Data Movement
• Broadcom TechDocs, VKS Standard Packages release notes
• VCAP-VKS 3V0-24.25 official exam guide

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts