# Back up and restore the server

This page is for on-premises servers. In the cloud, IZT looks after the server.

## What to back up

| What | Where | How often |
|---|---|---|
| The database | Your database server | Regularly, with your usual database backup tools |
| The data folder | The volume mounted at `/data` | After first setup, and whenever the database key changes |
| The recovery kit | The two files you downloaded during setup | Once, kept offline |

Every secret in the database is encrypted with the **database key**, which is not stored in the database. A database backup on its own cannot be restored: you also need the key, either from the data folder (`/data/secrets`) or from the **database key backup** in your recovery kit.

:::caution[Keep the pieces apart]
Store the recovery kit offline and away from your database backups, with its passphrase somewhere else again. Someone who has all three has everything.
:::

### If you change the database key

An instance owner can rotate the database key under **Instance** › **Identity**, in the **Change the identity key** card, with **Rotate database key**. Blink seals every secret again with a new key, and the old database key backup no longer opens anything, so:

1. Enter a passphrase for the new backup (at least 12 characters), confirm it, and select **Rotate and download**.
2. Prove the downloaded backup opens with that passphrase when the console asks.
3. Replace the old database key backup in your recovery kit.
4. Back up the data folder again.

If you have lost the database key backup file, rotating the database key is also how you get a new one.

## Restore on new hardware

Use this when the original server is gone and you are bringing Blink back from backups.

1. Restore your database backup on the new database server.
2. Copy the database key backup (`blink-kek-<instance>-<date>.json`) to the new host, somewhere the container can read it. The container runs as an unprivileged user (uid 65532), so the file must be readable by that user.
3. Restore the database key into a new, empty data volume. The server asks for the recovery kit passphrase:

   ```sh
   docker run --rm -i -v blink-data:/data -v /path/to/kit:/kit:ro \
     <blink-server-image> -restore-kek /kit/blink-kek-<instance>-<date>.json
   ```

   Instead of typing it, you can pass the passphrase in the `BLINK_KEK_PASSPHRASE` environment variable. The command writes the key into `/data/secrets`, prints which instance it restored, and exits.
4. Start the server as usual (see [Install Blink on your own server](/install/on-premises-server/)), pointing it at the restored database and the same data volume.
5. Point your DNS name at the new server.

The server refuses to start if the data volume belongs to a different installation than the database, so you cannot mix them up by accident.

Because the server's identity comes back with the database, your Access agents reconnect on their own once the DNS name points at the new server. You do not need to reinstall them.

:::note
Copying the existing `/data` volume to the new host works too. Restoring from the recovery kit is for when that volume is lost.
:::

## If the server's identity was lost or stolen

If you think someone else has a copy of your server's identity key (for example, a stolen backup or disk image), the recovery key in your recovery kit lets you replace it without reinstalling your agents. An instance owner does this under **Instance** › **Identity** with **Recover with the recovery file**. The change goes to IZT and then to every Access agent, and you get a new recovery file. If the server itself may be compromised, rebuild it from clean backups first, then recover. If you are unsure, contact [IZT](https://izt.app) before you start.