Deploying and Configuring
Veeam Kasten

What has to be true before you install

Four things have to be true before the install is worth attempting — platform, Helm, namespace, and storage — and each one has a command or setting that proves it. Nothing here touches the cluster yet.

1. Platform

The supported operating system is Linux, and the architecture you pick decides which capabilities are available. Read the last two rows twice: Veeam repository exports and vSphere block mode exports are the features that tie Veeam Kasten back to the estate you already run.

Supported platforms and the capabilities each architecture carries.

2. Helm

The first prerequisite step is to verify the Helm 3 package manager and configure access to the Veeam Kasten Helm charts repository. Helm is assumed to be compatible with n-3 versions of the Kubernetes it was compiled against, so match it to the cluster's version.

helm repo add kasten https://charts.kasten.io/

Helm confirms the repository was added — the chart repository, one of three network paths covered below.

The chart's integrity can be verified using the published public key: pass the --verify flag along with the --keyring when running helm install.

helm install k10 kasten/k10 --namespace=kasten-io --verify --keyring=/path/to/downloaded/RPM-KASTEN

3. Namespace

Create the installation namespace — by default, kasten-io. On install, Helm will automatically generate a new Service Account granting Veeam Kasten the required access to Kubernetes resources; a pre-existing Service Account can be used instead.

kubectl create namespace kasten-io

Treat kasten-io like the machine a Veeam Backup & Replication server runs on: the product's own home, not somewhere protected workloads live. The name is a default rather than a hard requirement, but the documentation uses kasten-io throughout — staying on it keeps every copied command working unchanged.

4. Storage

Veeam Kasten assumes that SSDs or similar fast storage media support the default storage class; if the default storage class doesn't meet the performance requirements, add the following option to the Veeam Kasten Helm installation commands.

--set global.persistence.storageClass=<storage-class-name>

That flag governs where Veeam Kasten keeps its own state. The second storage question — the one that decides how good the resulting protection can be — is about the workloads you protect: using a CSI driver with VolumeSnapshot support is a requirement to build a good data protection solution using Veeam Kasten. Though Veeam Kasten supports Generic Storage Backups for storage systems with no CSI drivers, this approach is not recommended.

Let the primer tool answer the storage question for you

Run the pre-flight checks, read the output line by line, and make the call: is this cluster ready for an install? The checklist at the end turns that call into something you can hold.

curl https://docs.kasten.io/downloads/9.0.2/tools/k10_primer.sh | bash

The documented command to deploy the pre-check tool.

To run the pre-flight checks in an air-gapped environment, use the following command instead, substituting your own registry for the example one.

curl https://docs.kasten.io/downloads/9.0.2/tools/k10_primer.sh | bash /dev/stdin -i repo.example.com/k10tools:9.0.2

What a good result looks like

The documentation shows example primer output from a Kubernetes cluster deployed in Digital Ocean. Read it as four verdicts about the cluster followed by one verdict per storage provisioner. It is an old sample — Kubernetes v1.17.13, CSI group v1alpha1 — so expect your own run to name a current version and the v1 group; the shape of the output is what to take from it.

Kubernetes Version Check:
   Valid kubernetes version (v1.17.13) - OK
RBAC Check:
   Kubernetes RBAC is enabled - OK
Aggregated Layer Check:
   The Kubernetes Aggregated Layer is enabled - OK
CSI Capabilities Check:
   Using CSI GroupVersion snapshot.storage.k8s.io/v1alpha1 - OK

Then, per provisioner, the tool reports the StorageClasses it found and the VolumeSnapshotClasses attached to them — the part that answers Section 1's storage question.

Volume Snapshot Classes:
      csi-rbdplugin-snapclass
         Has k10.kasten.io/is-snapshot-class annotation set to true - OK
         Has deletionPolicy 'Retain' - OK

Two lines, two different things: the annotation line says Veeam Kasten will recognise this VolumeSnapshotClass and use it; the deletion-policy line says what happens to the underlying snapshot when the Kubernetes object is removed. Where a provisioner has no deletion policy set, the same output reports it plainly as Missing deletionPolicy, using default.

Read that last line as information, not as a finding to clear. It carries no - OK because it reports a state rather than passing a test, and the state is the acceptable one: the guide describes the default deletion policy as the default and recommended one, and the release notes record that a Retain deletionPolicy for VolumeSnapshotClasses is no longer required or recommended. The annotation line directly above it is what gates whether snapshots work at all — stop on that one if it is missing.

The deeper CSI check

The documentation strongly recommends using the same tool for a more comprehensive CSI validation — a real end-to-end rehearsal that creates a sample application with a persistent volume, writes data to it, snapshots the volume, creates a new volume from the snapshot, and validates the data in the new volume. Run the first command to derive the list of provisioners with their StorageClasses and VolumeSnapshotClasses, then the second with a valid StorageClass to deploy the pre-check tool.

curl -s https://docs.kasten.io/downloads/9.0.2/tools/k10_primer.sh | bash

Then the deeper check, pointed at a StorageClass from that output:

curl -s https://docs.kasten.io/downloads/9.0.2/tools/k10_primer.sh | bash /dev/stdin csi -s ${STORAGE_CLASS}

One command, then two minutes of watching pods

The install itself is one command. The judgment is in the flags your platform needs alongside it — and in proving the install succeeded before you go looking for the dashboard.

The install command

For a certified Kubernetes distribution installed on-premises or in another environment, follow the general instructions. Which distributions qualify is a matrix question: the supported Kubernetes and OpenShift versions are published in the guide, and versions no longer actively supported by their vendor or community are not supported.

helm install k10 kasten/k10 --namespace=kasten-io

In a public cloud the same command carries credential flags: on Amazon EKS, or any other Kubernetes distribution running on EC2, two environment variables holding the access key id and secret access key are defined first and passed through.

helm install k10 kasten/k10 --namespace=kasten-io \
      --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
      --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

Before installing on Amazon EKS, determine the preferred authentication mechanism — long-term access keys or IAM Roles for service accounts — because that choice affects the necessary steps and prerequisites.

Where “as specified elsewhere” points, platform by platform

AWS is the worked example; the other platforms have their own credential flags, each on its own install page in the guide. Find yours before the install window.

helm install k10 kasten/k10 --namespace=kasten-io \
      --set secrets.azureTenantId=<tenantID> \
      --set secrets.azureClientId=<azureclient_id> \
      --set secrets.azureClientSecret=<azureclientsecret>

The documented Azure install command for a service principal.

--set secrets.vsphereUsername=<vsphere username> \
  --set secrets.vspherePassword=<vsphere password> \
  --set secrets.vsphereEndpoint=<vsphere ip or hostname>

Setting up vSphere credentials requires configuring all of these flags during the execution of helm install or helm upgrade; alternatively an existing secret can be used with --set secrets.vsphereClientSecretName=<secret name>.

Verifying the install

To validate that Veeam Kasten has been installed properly, the following command can be run in Veeam Kasten's namespace — the install default is kasten-io — to watch for the status of all Veeam Kasten pods.

kubectl get pods --namespace kasten-io --watch

The --watch flag holds the terminal open — the command working, not hanging. Read until every pod shows Running, then press Ctrl+C. It may take a couple of minutes for all pods to come up.

What you should see, once the pods settle, is a table in which every row reads Running.

NAMESPACE  NAME                                READY  STATUS          RESTARTS  AGE
kasten-io  aggregatedapis-svc-b45d98bb5-w54pr  1/1    Running         0         1m26s
kasten-io  auth-svc-8549fc9c59-9c9fb           1/1    Running         0         1m26s
kasten-io  catalog-svc-f64666fdf-5t5tv         2/2    Running         0         1m26s

An excerpt of the documented example output; a real cluster lists more services. If pods are stuck in any other state, the documentation directs you to the support documentation to debug further.

If pods do not reach Running

“Go to the support documentation” is thin comfort at 21:40 in a change window, so collect the evidence before you change anything: the guide asks you to run the debug script as a first step to get information to support, assuming your default kubectl context points at the cluster and Veeam Kasten is installed in the kasten-io namespace.

curl -s https://docs.kasten.io/downloads/9.0.2/tools/k10_debug.sh | bash;

The script generates a compressed archive k10_debug_logs.tar.gz with separate log files for Veeam Kasten services. Recent builds can also produce support logs from the System Information page under the Settings menu.

Reaching the dashboard, then locking it down

Get into the dashboard from your own machine first. Then the two decisions that outlive tonight: which of the four ways in other people get, and which authentication mode belongs in front of it.

kubectl --namespace kasten-io port-forward service/gateway 8080:80

To establish a connection to the dashboard, use this kubectl command to forward a local port to the Veeam Kasten ingress port. The dashboard will then be available at http://127.0.0.1:8080/k10/#/.

Unmanaged means no policy has claimed the application yet — the normal state of a cluster on day one. The next two modules move applications out of that column.

Four ways in

Following a successful installation, there are several options for setting up access to the Veeam Kasten dashboard. Pick the tab that matches how the dashboard needs to be reached.

helm upgrade k10 kasten/k10 --namespace=kasten-io \
    --reuse-values \
    --set externalGateway.create=true \
    --set auth.tokenAuth.enabled=true

kubectl --namespace kasten-io get service gateway-ext \
    -o jsonpath='{.status.loadBalancer.ingress[].hostname}'

The four authentication modes you choose at install

During installation, you have an option to choose an authentication mode: Direct Access, Basic Authentication, Token-based Authentication, or OpenID Connect — and when exposing the dashboard externally, it is required that an authentication method is properly configured to secure access. Two more modes matter in an enterprise: an Active Directory or LDAP server, enabled with --set auth.ldap.enabled=true and its supporting Helm values, and on Red Hat OpenShift the OpenShift OAuth server, enabled with --set auth.openshift.enabled=true.

Two details are worth carrying forward. First: token-based authentication is always enabled as a secondary authentication type to let Veeam Kasten Multi-Cluster Manager components and Veeam Backup & Replication services work with Veeam Kasten. Second: Basic Authentication needs htpasswd credentials in the format of username:hashedpassword, generated using either an online tool or the htpasswd binary found on most systems, supplied with the helm install or upgrade command — the guide publishes no htpasswd invocation to copy, and the worked example below shows the string in place.

--set auth.basicAuth.enabled=true \
--set auth.basicAuth.htpasswd='example:$apr1$qrAVXu.v$Q8YVc50vtiS8KPmiyrkld0'

Alternatively, an existing secret containing an htpasswd file can be referenced with --set auth.basicAuth.secretName=my-basic-auth-secret; the secret must be in the Veeam Kasten namespace, created with the key named auth and the htpasswd-generated password as the value in its data field.

For token authentication, the most common token type is a service account bearer token, which kubectl will generate for a service account with the proper permissions; generating a token with an expiration period is the recommended practice.

kubectl --namespace kasten-io create token my-kasten-sa --duration=24h

The example assumes Veeam Kasten is installed in the kasten-io namespace and the ServiceAccount is named my-kasten-sa.

One annotation decides whether snapshots work

The annotation that tells Veeam Kasten which VolumeSnapshotClass to use, the exactly-one-per-provisioner rule that fails silently until snapshots do, and the reason a CSI snapshot on its own is still not a backup.

The annotation

For each CSI driver, ensure that a VolumeSnapshotClass has been added with the Veeam Kasten annotation k10.kasten.io/is-snapshot-class: "true". If an existing VolumeSnapshotClass cannot be modified to match, a new one can be created with the required annotation. The example below is the guide's own correctly configured Azure Disk VolumeSnapshotClass.

$ kubectl get volumesnapshotclass csi-azuredisk-vsc -o yaml
apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Delete
driver: disk.csi.azure.com
kind: VolumeSnapshotClass
metadata:
  annotations:
    k10.kasten.io/is-snapshot-class: "true"
    snapshot.storage.kubernetes.io/is-default-class: "true"
  creationTimestamp: "2024-10-28T14:48:50Z"
  generation: 1
  name: csi-azuredisk-vsc
  resourceVersion: "2502"
  uid: 9ebec324-0f09-42fa-aace-39440b3184b6
parameters:
  incremental: "true" # available values: "true", "false" ("true" by default for Azure Public Cloud, and "false" by default for Azure Stack Cloud)
  networkAccessPolicy: "AllowAll"
  publicNetworkAccess: "Enabled"

The annotation is what matters; the API group has moved on. The guide also shows Alpha and Beta snapshot API examples, but on every Kubernetes release in this build's support matrix the group is snapshot.storage.k8s.io/v1, as shown here. The driver, name, timestamps, deletion policy and parameters belong to the sample Azure cluster — yours will differ.

Whenever Veeam Kasten detects volumes provisioned via a CSI driver, it looks for a VolumeSnapshotClass with the Veeam Kasten annotation for that driver and uses it to create snapshots; an existing VolumeSnapshotClass can be annotated in place.

kubectl annotate volumesnapshotclass ${VSC_NAME} \
       k10.kasten.io/is-snapshot-class=true

The check is one command. List the VolumeSnapshotClasses that carry the annotation and count the answers per provisioner.

kubectl get volumesnapshotclass -o json | \
       jq '.items[] | select (.metadata.annotations["k10.kasten.io/is-snapshot-class"]=="true") | .metadata.name'

As an alternative to annotating the VolumeSnapshotClass, a StorageClass can be annotated instead, and all volumes created with that StorageClass will be snapshotted by the specified VolumeSnapshotClass.

kubectl annotate storageclass ${SC_NAME} \
      k10.kasten.io/volume-snapshot-class=${VSC_NAME}

Why a snapshot is not a backup here either

Infrastructure profiles: key steps

Some storage integrations need credentials of their own, held in an infrastructure profile: to enable snapshots and restores from AWS, an Infrastructure Profile must be created from the Infrastructure page of the Profiles menu. On VMware, a configured vSphere Infrastructure Profile makes Veeam Kasten create First Class Disk snapshots of volumes via vCenter.

This walkthrough is abbreviated. The Create Infrastructure Profile wizard has three steps — Name and Provider, Configuration, and Summary — and the screens below are the ones the documentation illustrates; treat them as a shape to recognise rather than a complete click path. Under the hood the profile is a Kubernetes custom resource: the guide's API examples create an AWS Infrastructure Profile declaratively with kubectl apply, so in a GitOps-managed rollout this step does not have to stay a dashboard click-path.

The repository-shaped object, and where to point it

Why a location profile exists, what you can point it at, and creating your first one — including a Veeam repository profile if your existing estate is where this data should go.

Location Profile creation is accessed from the Location page of the Profiles menu, or via the CRD-based Profiles API; to create one, click Create New Profile on the profiles page.

Before you click that button, check the path. The guide's disaster-recovery guidance states plainly that clusters must have network connectivity to at least one external storage location, with a corresponding location profile configured to allow access to it. Upon clicking Submit the dialog will validate the input data — a firewalled endpoint or unresolvable DNS name reaches you as a failed validation on the profile card, so confirming reachability from the cluster first turns a puzzling red badge into a five-minute check already done.

What you can point it at

Veeam Kasten creates Kopia repositories in object store locations, using Kopia as a data mover, which implicitly provides support to deduplicate, encrypt and compress data at rest, and it performs periodic maintenance on these repositories to recover released storage. That trio is what a Veeam Backup & Replication backup file already gives you — Kopia does the work here instead of the backup server. If an S3-compatible system not hosted by a supported cloud provider is used, an S3 endpoint URL must be specified and SSL verification can optionally be disabled — recommended only for test setups.

Immutability is a toggle, and it belongs on by default. If the bucket has object locking enabled, set the Enable Immutable Backups toggle: in a locked bucket, restore point data cannot be deleted or modified within the set protection period, even with administrator privileges, so a clean copy survives an attacker who has obtained privileged object store credentials.

Treat the toggle as the standing choice for every production export profile.

Pointing it at a Veeam repository

This is the profile that connects the two halves of your estate. Select Create New Profile and specify Veeam Repository as the provider type; provide the DNS name or IP address of the Veeam backup server in the Veeam Backup Server field, the API port (pre-configured with the installation default), and the name of a backup repository on that server in the Backup Repository field.

Provide access credentials in the Username and Password fields, and ensure Access Permissions are granted within Veeam Backup & Replication for the specified account, or the related security group, and for the backup repository. Treat that as a pre-implementation task on the Veeam Data Platform side: the account exists, scoped to the one repository this profile names, before anyone opens the dialog.

On submit, the dialog validates the input, and communication with the server uses SSL and requires that the server's certificate be trusted by Veeam Kasten — an untrusted or self-signed certificate is a failure mode you can predict rather than discover. Enabling the Skip certificate chain and hostname verification option disables certificate validation: available, and not the answer you want in production.

What you should see when it works

When a location profile is created, the config profile will be created and a profile appears on the profiles page — provider, name, validation status, and available actions.