Deploy Velero

Use the velero package to deploy the Velero server and node agent, connect them to S3-compatible object storage, and schedule recurring backups.

This guide uses Velero 1.15.2 with the AWS object-store plugin. It assumes you have an existing bucket and credentials that can read, write, list, and delete objects in it.

Install the Velero CRDs

The Kix package creates Velero resources but does not install their custom resource definitions. Install the matching CRDs before the first deployment:

❱ velero install --crds-only --dry-run -o yaml | kubectl apply -f -

Use the Velero 1.15.2 CLI for this command. When upgrading Velero, update its CRDs before deploying resources built for the new version.

The package can also perform this step inside the cluster. Setting config.upgradeCRDs.enable = true creates a Job and ServiceAccount that run velero install --crds-only on every apply. The package does not create the cluster-scoped RBAC needed by that ServiceAccount, so provide it before enabling this option.

Create the credentials Secret

Create a local file named credentials-velero in the format expected by the AWS plugin:

credentials-velero

[default]
aws_access_key_id=<access-key-id>
aws_secret_access_key=<secret-access-key>

Create the namespace and Secret before deploying Velero:

❱ kubectl create namespace velero-system

❱ kubectl create secret generic velero-credentials --namespace velero-system --from-file=cloud=./credentials-velero

Keep the credentials file out of version control. If your platform already creates Kubernetes Secrets, use that system to create the same Secret and cloud key.

Configure Velero

Add a Velero instance to the cluster:

how-to/package-stacks/velero-cluster.nix (L17–L40)

      instances.velero-system.velero = {
        package = packages.velero;
        config = {
          credentials.secretName = "velero-credentials";

          backupStorageLocation = {
            provider = "velero.io/aws";
            bucket = "example-cluster-backups";
            config = {
              region = "eu-central-1";
              s3ForcePathStyle = "false";
            };
          };

          schedules.daily = {
            schedule = "0 2 * * *";
            template = {
              includedNamespaces = [ "applications" ];
              ttl = "720h0m0s";
              defaultVolumesToFsBackup = true;
            };
          };
        };
      };

View source on GitHub ↗

Replace example-cluster-backups and the region with values for your bucket. For an S3-compatible service with a custom endpoint, also set s3Url and set s3ForcePathStyle according to the service’s requirements.

The daily schedule backs up the applications namespace at 02:00 UTC, retains each backup for 30 days, and uses the node agent for volume data. Change the namespace selection, schedule, and retention period to match your recovery policy.

Check the generated configuration

Evaluate the cluster:

Run in kix-examples/

❱ kix check how-to-package-velero
 TOOL         RESULT  DETAILS                                                       
 eval         pass    30 manifests evaluated                                        
 kubeconform  pass    skipped (this validation tool is not yet integrated with Kix) 
 pluto        pass    skipped (this validation tool is not yet integrated with Kix) 
 kyverno      pass    skipped (this validation tool is not yet integrated with Kix) 
 scorecard    pass    0 errors, 13 warnings, 3 info

Inspect the backup location and schedule that Kix will apply:

Run in kix-examples/ Output excerpt

❱ kix build how-to-package-velero --output json Show output

[
  {
    "apiVersion": "velero.io/v1",
    "kind": "BackupStorageLocation",
    "metadata": {
      "name": "default",
      "namespace": "velero-system"
    },
    "spec": {
      "accessMode": "ReadWrite",
      "config": {
        "region": "eu-central-1",
        "s3ForcePathStyle": "false"
      },
      "credential": {
        "key": "cloud",
        "name": "velero-credentials"
      },
      "default": true,
      "objectStorage": {
        "bucket": "example-cluster-backups"
      },
      "provider": "velero.io/aws"
    }
  },
  {
    "apiVersion": "velero.io/v1",
    "kind": "Schedule",
    "metadata": {
      "name": "daily",
      "namespace": "velero-system"
    },
    "spec": {
      "schedule": "0 2 * * *",
      "template": {
        "defaultVolumesToFsBackup": true,
        "includedNamespaces": [
          "applications"
        ],
        "ttl": "720h0m0s"
      }
    }
  }
]

The backup location refers to the existing velero-credentials Secret. Its contents are not part of the rendered manifests.

Deploy and verify

Deploy Velero, then check the server, backup location, and schedule:

Run in kix-examples/

❱ kix deploy how-to-package-velero

❱ kubectl rollout status deployment/velero --namespace velero-system

❱ velero backup-location get

❱ velero schedule get

The backup location should report Available. Confirm the complete path by starting a backup and waiting for it to finish:

❱ velero backup create initial-applications-backup --include-namespaces applications --wait

❱ velero backup describe initial-applications-backup --details

If the location is unavailable, inspect it and the server logs:

❱ kubectl describe backupstoragelocation default --namespace velero-system

❱ kubectl logs deployment/velero --namespace velero-system --since=10m