Learn Velero - Your First Backup

#Introduction

Velero is installed and the BSL shows Available from episode 3. Now comes the moment you've been waiting for: your first backup. Don't back up the entire cluster right away — start with a single namespace containing a simple workload, for example an nginx application with one PVC.

In this episode you'll understand what a backup actually produces: not just a "file copy", but two layers of data — resource manifests and volume contents — packaged and uploaded to object storage.

#Setting Up a Test Workload

Create an app namespace with an nginx Deployment and a PVC that writes a file:

workload.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: app
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          volumeMounts:
            - mountPath: /usr/share/nginx/html
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: app-data

kubectl apply -f workload.yaml
kubectl exec -n app deploy/nginx -- sh -c 'echo "hello velero" > /usr/share/nginx/html/index.html'

#Your First Backup

#Creating the Backup

velero backup create my-backup --include-namespaces app

This command creates a Backup object in the cluster; the Velero server immediately starts fetching all resources in the app namespace, including the PVC — and (because we installed with --default-volumes-to-fs-backup) backs up the volume contents via the node-agent.

velero backup get

The status will change New → InProgress → Completed. Completed means success; other statuses (PartiallyFailed, Failed) are dissected in episode 16.

#Reading Backup Details

velero backup describe my-backup --details

Pay attention to the important parts of the output: the scope (which namespaces), the number of stored resources, and the list of volumes backed up with a success status. --details also shows the complete list of resources by type — useful for verifying that what you expected to be included really was included.

#What a Backup Contains

#Resource Manifests

Velero fetches every resource in the backup scope and stores it as JSON in object storage — exactly like kubectl get <resource> -o json for all selected resources. This covers Deployment, PVC, ConfigMap, Secret, Service, and more. For resources created by applications themselves (e.g. CRDs from operators), the CRDs are included automatically as long as they're in scope.

#Volume Data

The second layer is the persistent volume contents. In the episode 3 installation, this is handled by node-agent + kopia: data is copied file-by-file to the BSL. On cloud clusters with a VSL, Velero creates block-level snapshots (EBS/PD/Disk) that are much faster. The detailed comparison is in episode 8; what matters here — both are stored via the same BSL, so backups stay portable.

mc ls local/velero/backups/my-backup/

Folder structure: velero-backup.json (metadata), resources/ (manifests), and kopia/ (volume data repository).

#Controlling the Backup Scope

#include-resources and exclude-resources

Not every resource needs to be backed up. Ephemeral resources that are automatically recreated (such as Pod, ReplicaSet) just waste space and slow down restore.

velero backup create web-backup \
  --include-namespaces app \
  --include-resources deployment,statefulset,configmap,secret,pvc,service

Conversely, exclude resources you don't need:

velero backup create no-events-backup \
  --include-namespaces app \
  --exclude-resources events,events.events.k8s.io

Excluded resources get recreated from their dependencies during restore — for example, a Pod that wasn't backed up still gets created because its Deployment was backed up.

#Targeting a Specific BSL

If the cluster has multiple BSLs, choose the storage location:

velero backup create archived-backup \
  --include-namespaces app \
  --storage-location backups-archive

#Closing

Key takeaways:

• First backup: velero backup create my-backup --include-namespaces app; success means status Completed.
• velero backup describe --details shows the scope and backed-up volumes.
• A backup has two layers: resource manifests (JSON) + volume data (cloud snapshot or kopia/restic).
• --include-resources/--exclude-resources controls resource types; avoid backing up runtime artifacts.
• Backups are stored in the BSL and remain portable across clusters.

In episode 5 next, we cover the opposite direction: restore — recovering an application from backup, including selective restore per resource and namespace, and --namespace-mappings for restoring data into a different namespace.