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

# Backup & Restore

> Protect FRP Auto Deploy identity, PKI, registry, and configuration before disaster recovery or major maintenance.

# Backup & Restore

The FRP Auto Deploy server contains state that is more important than the software binaries themselves. Backups protect the trust and reservation data needed to keep existing clients working after recovery.

## What you are protecting

```mermaid theme={null}
flowchart TB
    B[Server backup]
    B --> C[Configuration]
    B --> P[Project PKI / CA]
    B --> T[FRP token]
    B --> R[Client registry]
    B --> E[Enrollment state where applicable]

    P --> X[Existing client trust]
    R --> Y[CLIENT IDs + service metadata]
    R --> Z[Persistent public-port reservations]
```

## Create a backup

```bash theme={null}
sudo frpctl create backup
```

Store the resulting backup as sensitive infrastructure material.

## Important persistent state

At minimum, understand these locations:

```text theme={null}
/etc/frp-auto-deploy/config.json
/etc/frp-auto-deploy/pki/
/etc/frp/server_token
/var/lib/frp-auto-deploy/registry.json
```

The supported backup format also handles related state according to the installed release.

## Restore

```bash theme={null}
sudo frpctl restore backup <path>
```

Restore is not a blind `cp -r`. The supported flow is designed around validation and rollback behavior.

```mermaid theme={null}
flowchart LR
    A[Validate archive] --> B[Snapshot current state]
    B --> C[Restore saved state]
    C --> D[Restart required services]
    D --> E[Run health checks / doctor]
    E -->|success| F[Recovered]
    E -->|failure| G[Rollback / fail safely]
```

## Why the CA matters

Existing clients trust the project's private CA. Losing the CA private key can force advanced trust recovery or re-establishment. A normal reinstall/update should not intentionally rotate that CA.

## When to create a backup

* before high-risk maintenance or migration
* before a restore test
* before changing topology if rollback matters
* on a regular operational schedule appropriate for your environment
* after meaningful stable changes to client/service inventory when recovery point matters

## After restore

```bash theme={null}
sudo frpctl show version
sudo frpctl show status
sudo frpctl show clients
sudo frpctl doctor
```

Then verify one or more representative public service paths.

```mermaid theme={null}
flowchart LR
    U[Internet user] -->|expected public port| S[Restored server]
    S --> C[Existing client]
    C --> T[Target service]
```

## What not to do

* do not treat the PKI directory as disposable configuration
* do not restore only `frps.toml` and expect identity/port state to follow
* do not copy registry fragments manually between unrelated servers
* do not store backups in a public location

<Warning>
  Backups can contain highly sensitive trust and authentication material. Protect them at least as carefully as the production server state they represent.
</Warning>