> ## 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 in place

> Restore a backup into an existing deployment.

## What is implemented

The Admin UI restore dialog supports **Override current instance**. It calls the restore API for the existing deployment with:

```json theme={null}
{ "backup": { "name": "<backup-name>", "namespace": "<namespace>" } }
```

The backend validates that the target cluster exists, the backup exists, and the backup is marked restorable before creating a restore resource.

## Restore from Admin UI

1. Open **Deployments**.
2. Open the target deployment.
3. Go to **Backups**.
4. Select **Restore** on the backup to use.
5. Choose **Override current instance**.
6. Select **Restore Now**.

Restoring into the current deployment replaces current data with the selected backup data. Coordinate application downtime before starting the restore.

## Validate

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

In the Admin UI, review **Backups**, **Events**, and deployment health after the restore finishes.

## Failure conditions

* The restore fails if the target cluster does not exist.
* The restore fails if the backup does not exist.
* The restore fails if the backup is not ready for restore.