Velero With Wasabi

Velero is open-source software for backing up Kubernetes pod data, and Wasabi can be used to store Velero backups. This article outlines the procedure for setting up Velero for use with Wasabi.

The data restoration process is handled by your specific backup software application. As many variables can affect your unique environment, Wasabi strongly recommends that you seek guidance from your backup software's technical support resources if you encounter difficulties or have application-specific inquiries.

Requirements

Active Wasabi Cloud Storage Account.
Access to the Wasabi Console as the account root user.
Wasabi bucket created to store your backups. Do not enable Object Lock or Versioning. See Creating a Bucket for details on this procedure.
This solution was tested with Velero version 1.18.0 running on Ubuntu Linux version 24.04.4 with Kubernetes version v1.32.
Access to your Kubernetes server.

Configuring Wasabi Console

Configure a policy for the velero user (to be created below) using the following policy. See Creating and Deleting a Policy for instructions on creating a policy. We named the policy VeleroPolicy in our example. Change YOUR_BUCKET_NAME to your own bucket name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:PutObject",
        "s3:PutObjectTagging",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME"
    }
  ]
}

Create a Velero user and attach the previously created policy to it. See Creating a User for details.
- Allow programmatic -only access, not console access.
- Do not require Multi-Factor Authentication (MFA).
- It is not necessary to assign the user to a group.
- Save the access and secret keys in a secure location.

Configuring Velero

These instructions assume Velero runs on the same server as Kubernetes.

Log in to your Kubernetes server.
Create a file with your Wasabi Velero user’s access and secret keys as shown below. We named our file credentials-velero.
```
[wasabi]
aws_access_key_id=<YOUR_VELERO_USER_ACCESS_KEY>
aws_secret_access_key=<YOUR_VELERO_USER_SECRET_KEY>
```
If Velero is not installed, you can install it using the following commands. Replace YOUR_BUCKET_NAME with your bucket name, and replace the region and s3Url with the region and URL where your bucket is located.
These configuration examples use Wasabi’s us-east-1 storage region. Use the region where your bucket is located. For a list of regions, see Available Storage Regions.
```
BUCKET=YOUR_BUCKET_NAME
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.13.0 \
  --bucket $BUCKET \
  --secret-file ./credentials-velero \
  --backup-location-config region=us-east-1,s3Url=https://s3.us-east-1.wasabisys.com \
  --use-node-agent \
  --default-volumes-to-fs-backup
```
If Velero is already installed, you may instead just create a Wasabi backup storage location. Replace YOUR_BUCKET_NAME with your bucket name, and replace the region and s3Url with the region and URL where your bucket is located. The plugin (first command) is only required if it is not already installed.
Ensure your Velero installation is configured with the following options so that Velero performs filesystem backups for all volumes by default.
--use-node-agent
--default-volumes-to-fs-backup
```
velero plugin add velero/velero-plugin-for-aws:v1.13.0

kubectl create secret generic -n velero wasabi-credentials \
--from-file=wasabi=<PATH_TO_FILE>/credentials-velero

BUCKET=YOUR_BUCKET_NAME

velero backup-location create wasabi \
  --provider aws \
  --bucket $BUCKET \
  --credential=wasabi-credentials=wasabi \
  --config region=us-east-1,s3Url=https://s3.us-east-1.wasabisys.com
```

Performing a Test Backup and Restore

For our example, we will create a test nginx pod for backup and restoration to avoid disturbing other Kubernetes pods.

Create a test namespace of backup-test-ns.
```
kubectl create namespace backup-test-ns
```

Create a test configuration file by issuing the following command.

cat <<EOF > backup-test.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backup-test-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: backup-test-pod
spec:
  volumes:
    - name: backup-test-storage
      persistentVolumeClaim:
        claimName: backup-test-claim
  containers:
    - name: backup-test-container
      image: nginx
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: backup-test-storage
EOF

Create the pod.

kubectl apply -n backup-test-ns -f backup-test.yaml

Make a small change to identify the nginx instance prior to being backed up.

kubectl exec pod/backup-test-pod -n backup-test-ns \
-- sh -c "echo 'Velero backup test successful' \
> /usr/share/nginx/html/index.html"

Create a backup. You may omit the --storage-location wasabi if you installed Velero as part of this process which has Wasabi set as the default location.
```
velero backup create test-restore-backup \
--include-namespaces backup-test-ns \
--storage-location wasabi
```
Check the status of the backup. It should show the Phase as Completed in green once the backup is finished.
```
velero backup describe test-restore-backup
```
Delete the test namespace.
```
kubectl delete namespace backup-test-ns
```

Restore the backup.

velero restore create test-restore-verify --from-backup test-restore-backup

Issue the following commands to see if the restore was successful. The first command should show a STATUS of Running and the second command output should read “Velero backup test successful”.
```
kubectl get pods -n backup-test-ns

kubectl exec pod/backup-test-pod -n backup-test-ns \
-- sh -c “cat /usr/share/nginx/html/index.html"
```
Delete the test namespace.
```
kubectl delete namespace backup-test-ns
```

Setting Up a Backup Schedule

Issue the following command to set up a schedule. In this example, we have the backup set to run every day at midnight. Adjust the Time-to-Live (TTL, when Velero will delete the backup) value to meet your organization’s policies. We have it set to 90 days, or 2160 hours. If you installed Velero as part of this procedure where Wasabi is set as the default storage location, omit the --storage-location wasabi portion of the command.
```
velero schedule create wasabi-backup --schedule="0 0 * * *" \
--storage-location wasabi --ttl 2160h
```
Log in to the Wasabi Console and verify the backups are being stored in your bucket after the schedule has run once.