Restore a FalkorDB deployment to a point in time

​

Turn on continuous backups

1

Create an aof schedule

Open the deployment, go to Schedules, and select New Schedule. Choose the aof backup method and set Retention to how far back you want to be able to restore, for example 7d.With the API:

POST /api/clusters/<deployment>/backups/schedules?namespace=<namespace>

{
  "scheduleName": "<deployment>-pitr",
  "backupMethod": "aof",
  "frequency": "0 3 * * *",
  "retentionPeriod": "7d"
}

The cron frequency doesn’t time anything for aof: the continuous backup starts as soon as the schedule is enabled and runs until it is disabled.On a sharded deployment created before this release, the schedule can be refused with Backup method 'aof' is not supported by backup policy. KubeBlocks adds the new method to a deployment’s backup policy the next time it reconciles the deployment. Change any annotation on the deployment to make it reconcile now, then create the schedule again:

kubectl annotate clusters.apps.kubeblocks.io <deployment> -n <namespace> \
  falkordb.cloud/backup-policy-sync="$(date +%s)" --overwrite

2

Check that it is archiving

Go to Backups. A backup of type continuous appears with the status running. It stays running for as long as the schedule is enabled. Its Restorable field shows the range it covers once it has archived something.

kubectl get backups.dataprotection.kubeblocks.io -n <namespace> \
  -l dataprotection.kubeblocks.io/backup-type=Continuous \
  -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,START:.status.timeRange.start,END:.status.timeRange.end

3

Keep full backups too

Keep a datafile or volume-snapshot schedule next to the aof one (sharded deployments offer datafile only). A continuous backup doesn’t carry offloaded graphs, and a full backup is what you restore when a point in time isn’t needed.

kubectl exec -n <namespace> <deployment>-falkordb-0 -c falkordb -- \
  sh -c 'redis-cli --no-auth-warning -a "$REDIS_DEFAULT_PASSWORD" CONFIG GET aof-timestamp-enabled'

​

What decides the restorable window

GET /api/clusters/<deployment>/restores/window?namespace=<namespace>

falkordb-admin backups restore-window <deployment> --namespace <namespace>

{
  "timeZone": "UTC",
  "ranges": [
    {
      "backupName": "<continuous-backup>",
      "backupNamespace": "<namespace>",
      "earliest": "2026-10-26T03:00:12Z",
      "latest": "2026-11-02T09:30:15Z"
    }
  ]
}

​

Restore

​

Admin UI

1. Open the deployment, then go to Backups.
2. Select Restore at the top of the page, or Restore to a point in time on the continuous backup.
3. Under Restore from, choose Point in time.
4. Choose a date and time. The picker starts at the latest restorable time, in your browser’s time zone, which is shown under it. Select Use UTC to choose the time in UTC instead. The restorable window is listed in both your time zone and UTC.
5. Enter a name for the new deployment.
6. Select Restore Now.

​

API

POST /api/clusters/<deployment>/restores/clone?namespace=<namespace>

{
  "newClusterName": "<new-deployment>",
  "restoreTime": "2026-11-02T08:00:00Z"
}

​

CLI

falkordb-admin backups clone <deployment> --namespace <namespace> \
  --newClusterName <new-deployment> --restore-time 2026-11-02T10:00:00+02:00

​

Check the restored data

kubectl get clusters.apps.kubeblocks.io -n <namespace> <new-deployment>
kubectl get restores.dataprotection.kubeblocks.io -n <namespace> \
  -o custom-columns=NAME:.metadata.name,PHASE:.status.phase | grep '^<new-deployment>-'

​

Sharded deployments

• Writes across shards. The shards agree on the restore time to the second, and to how closely the clocks of their nodes agree. A write that touched several shards, such as a client writing keys of different slots one after another, can come back on one shard and not another when it spans the restore time.
• After a change in shard count. KubeBlocks fixes a continuous backup’s shards when it starts, so after a scale-out the new shard is never archived, and a restore to a time before a scale-in would need the old shard count, which nothing records. Once a sharded deployment has a different number of shards than its continuous backup archives, the Admin Server leaves that backup out of the window, refuses to restore from it, and replaces it, whether the deployment was scaled in the Admin UI or not. Within a minute of the scale, it:
  1. disables the aof schedule. A scale-in waits for this: the continuous backup reads a removed shard’s volume, which KubeBlocks can’t delete while it’s in use;
  2. waits for the old continuous backup to stop running, and for any new deployment still being restored from it, then deletes it. A restore from it that failed holds this step until you delete the deployment it was creating;
  3. once the deployment is Running with its new shards, enables the schedule again, and KubeBlocks starts a new continuous backup.
  The new window begins when the new backup has archived every shard, a few minutes after the scale. Times before that can only be restored from a full backup, and a full backup taken before the scale restores to as many shards as it holds. Each step appears in the audit log, as system:continuous-backups. The Admin Server checks the shard count every minute. If a deployment is scaled and scaled back to its old shard count within that time, the continuous backup isn’t replaced, and a shard that existed only in between was never archived: a restore to a time while it held slots can miss the writes to them. Scale one step at a time, or check the restored data for that period. The Admin Server does this for an aof schedule created on the Schedules tab or with the API. For an aof entry enabled in a schedule KubeBlocks generated, take the same steps by hand: a running backup can’t be deleted, and enabling the schedule again without deleting the backup resumes the old one.

​

Limitations

• Replication lag. A continuous backup archives a replica when the deployment has one. A replica stamps a write with the time it applies it, not the time the primary committed it, so a write committed within the replication lag before the restore time (usually milliseconds) can be left out.
• Offloaded graphs. A continuous backup doesn’t package the dump files of offloaded graphs, so it can’t be relied on to bring them back. Restore a datafile or volume-snapshot backup, which the restore flow treats as full backups, when you need offloaded graphs.
• Restore in place. Like every restore, a point-in-time restore creates a new deployment. See Restore in place for how to replace a deployment’s data.
• One-second precision. The restore keeps every write stamped at or before the chosen second and drops the rest.