Redis

Published: 10 Mar. 2026 Last updated: 5 Oct. 2026

Summary

Redis is an open-source, in-memory, NoSQL data structure store. It is commonly used as a database, cache, and message broker. By storing frequently accessed data in RAM, Redis provides very low-latency access for high-performance applications. It supports several data structures, including strings, hashes, lists, sets, and sorted sets. Redis also provides optional persistence, allowing data to be saved to disk.

This Application Note explains how to use CloudCasa to back up and restore Redis running in Kubernetes. It covers the two most common ways to install Redis:

Helm chart - Redis is installed directly with a Helm chart. CloudCasa has been tested with Redis 8.10.2 installed using the Bitnami Redis Helm chart version 28.3.1.
Redis operator - Redis is created and managed by an operator. CloudCasa has been tested with Redis 7.0.15 created using the Redis operator.

The backup steps are the same for both methods. The restore steps are slightly different, and are described separately. The steps are expected to work with later versions of Redis, and with other installation methods, as well.

Before you start

Persistence must be enabled. CloudCasa backs up the data that Redis has saved to disk on its Persistent Volumes (PVs). If Redis does not use PVs, there is nothing on disk to back up. The Bitnami Helm chart enables persistence by default. With the Redis operator, persistence is enabled by adding storage.volumeClaimTemplate to the Redis resource.

Backup

It is recommended to define a full cluster backup, so that all resources Redis needs, including any cluster-scoped resources, are included and can be restored together. If you are defining a more granular backup, ensure that Redis namespaces are included, and that the option to backup PVs is enabled (which is the default).

A pre-backup App Hook is used to make Redis save its data to disk just before CloudCasa takes the backup.

Step 1: Find your Redis pods

Note the namespace where Redis is running, then list the pods and their labels:

kubectl get pods -n <redis-namespace> --show-labels

Make a note of:

A label that can uniquely identify Redis pods. For example:
- Bitnami Helm chart: app.kubernetes.io/name=redis
- Redis operator: app=<redis-resource-name>, for example app=test-redis
The name of the Redis container in the pod. For the Bitnami Helm chart this is redis. For the Redis operator it is the name of the Redis resource, for example test-redis. To check it:
```
kubectl get pod <redis-pod> -n <redis-namespace> -o jsonpath='{.spec.containers[*].name}'
```

The App Hook runs once on every pod that matches the label. If Redis has more than one pod, such as a primary and one or more replicas, the hook runs on each of them. This is expected: each Redis pod saves its data on its own PV, and all of these PVs are backed up, so running the hook on each pod makes sure every PV contains a completed save. Make sure that the label does not match any pods outside your Redis deployment.

Step 2: Create the pre-backup App Hook

In CloudCasa, go to Configuration → App Hooks and click “Add App Hook”. Fill in the fields as follows:

Name: A name for the hook, for example redis-pre-backup.

Type: Pre-backup

Pod selector: The label from Step 1, for example app.kubernetes.io/name = redis or app = test-redis.

Container name: The container name from Step 1, for example redis or test-redis.

Command:

sh -c '
  P="${REDIS_PASSWORD:-$(cat "${REDIS_PASSWORD_FILE:-/dev/null}")}"
  [ -n "$P" ] && export REDISCLI_AUTH="$P"
  BEFORE=$(redis-cli LASTSAVE) && [ "$BEFORE" -gt 0 ] || exit 1
  sleep 1
  redis-cli BGSAVE SCHEDULE | grep -qE "Background saving|already in progress" || exit 1
  for i in $(seq 1 60); do
    sleep 2
    [ "$(redis-cli LASTSAVE)" -gt "$BEFORE" ] && exit 0
  done
  echo "Redis save did not complete in 2 minutes" >&2
  exit 1
'

Click Save.

What this command does:

It finds the Redis password. The Redis operator provides the password in the REDIS_PASSWORD environment variable. The Bitnami Helm chart provides it in a file, named by the REDIS_PASSWORD_FILE environment variable. The command supports both. If neither is set, it runs without a password.
It checks that it can connect to Redis, and notes the time of the last successful save.
It tells Redis to save all of its data to disk. If Redis is busy rewriting its append-only file, the save starts as soon as the rewrite finishes.
It waits up to 2 minutes for the time of the last successful save to change. This only happens when the new save has completed, so the data on disk is complete before CloudCasa backs up the PVs.
If anything goes wrong, the command returns an error. For example: the password is wrong, Redis is not running, Redis cannot write to disk, or the save takes longer than 2 minutes.

Note: A failed App Hook does not stop the backup. The Redis PVs are still backed up, but CloudCasa marks the backup job as Partially Failed, with a message such as “Backup partially successful. … 2 of 2 app hooks failed”. In this case, the backed-up data may not include the most recent writes to Redis. Open the job on the Activity page and check its errors and warnings to see why the App Hook failed.

If your Redis uses a username in addition to a password (ACLs enabled), add --user "<your-username>" to each of the redis-cli calls in the command.

No Post-backup App Hook is needed, because saving does not leave Redis in a state that needs to be undone after the backup.

Step 3: Create a backup definition

Create a backup definition following the CloudCasa User Guide. Select a full cluster backup, and in the App Hooks section of the backup definition, add the pre-backup hook created in Step 2.

Restore

Restore to a namespace or cluster where Redis is not already running. Do not restore over a running Redis deployment. When Redis starts after the restore, it loads its data from the restored PVs. Replicas copy the data from the primary automatically.

Redis installed with a Helm chart

When creating the restore definition, select the namespace where Redis is installed. Make sure the PVs are included.

No operator or Custom Resource Definitions (CRDs) are needed. The restored StatefulSets start the Redis pods directly.

Redis installed with the Redis operator

When creating the restore definition, select the namespace where Redis is installed.

Also select the namespace where the Redis operator is installed, if the operator is not already running in the target cluster. The operator manages the Redis resources after they are restored. If the operator is not running, the restored Redis resources may not start correctly. If the operator is already running in the target cluster, restoring its namespace again is optional.

Important: Make sure the “Include all cluster-scoped resources” switch is enabled when creating the restore definition. This restores the CRDs for Redis resources, such as Redis or RedisCluster.

Note: If you need to remove a Redis deployment and its operator from a cluster, for example during testing, delete the Redis deployment first and wait until it is fully removed before deleting the operator. If both are deleted at the same time, the Redis deployment can get stuck while terminating, because the operator is needed to finish the cleanup.

Check the restored data

After the restore completes, check that the Redis pods are running:

kubectl get pods -n <redis-namespace>

Then check that your data is back, for example by counting the keys:

kubectl exec -n <redis-namespace> <redis-pod> -c <container-name> -- sh -c 'export REDISCLI_AUTH=${REDIS_PASSWORD:-$(cat ${REDIS_PASSWORD_FILE:-/dev/null} 2>/dev/null)}; redis-cli DBSIZE'

The number of keys should match the number before the backup.