> ## Documentation Index
> Fetch the complete documentation index at: https://docs.falkordb.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> FalkorDB is a graph database that speaks the Redis protocol. Queries are issued as OpenCypher through the GRAPH.QUERY and GRAPH.RO_QUERY commands, not over Bolt or a SQL connection.
> FalkorDB implements a subset of OpenCypher with proprietary extensions. Do not assume Neo4j-only syntax or procedures are available — check /cypher/cypher-support and /cypher/known-limitations before using a clause.
> FalkorDB is the successor to RedisGraph, but they are separate products. Do not present RedisGraph commands, versions, or limitations as current FalkorDB behavior.
> Use the official clients listed in /getting-started/clients rather than generic Redis or Neo4j drivers, and prefer the language the user is already working in.
> Configuration parameters are set with GRAPH.CONFIG SET or at startup; cite the exact parameter name from /getting-started/configuration rather than inventing one.
> This site covers four products: FalkorDB (core), FalkorDB Cloud, FalkorDB Enterprise, and the GraphRAG SDK. Name which one an answer applies to, since setup and operations differ.

# Restore to a new deployment

> Create a new deployment from an existing backup.

## Current implementation status

The backend has a clone endpoint for this workflow:

```text theme={null}
POST /api/clusters/<sourceClusterName>/restores/clone?namespace=<namespace>
```

The clone service creates a new cluster from the source cluster spec and adds the KubeBlocks restore annotation `kubeblocks.io/restore-from-backup`.

The current Admin UI **Create new instance from backup** option is not wired to this clone endpoint. It currently calls the regular restore endpoint using the new instance name as the target cluster name, which requires that target cluster to already exist. Treat the UI path for new-instance restore as incomplete until it is rewired to the clone endpoint.

## Backend requirements

The backend clone service validates:

* Source cluster exists.
* Backup exists.
* Backup method is `full`.
* Backup is ready for restore.
* Target cluster name does not already exist in the namespace.

The clone request body uses:

```json theme={null}
{
  "newClusterName": "<new-cluster-name>",
  "backupName": "<backup-name>",
  "backupNamespace": "<backup-namespace>",
  "volumeRestorePolicy": "Parallel"
}
```

`volumeRestorePolicy` defaults to `Parallel` when omitted. `Serial` is also accepted by the service type.

## Validate

```bash theme={null}
kubectl get clusters.apps.kubeblocks.io -n <namespace>
kubectl get clusters.apps.kubeblocks.io -n <namespace> <new-cluster-name> -o yaml
kubectl get pods -n <namespace>
```

Confirm the created cluster includes the restore annotation and reaches a healthy state.