# What is an encrypted backup of a secrets vault?

> An encrypted backup is a copy of a vault that can't be read without keys stored somewhere else. What to keep apart, and what a restore can't bring back.

URL: https://crunu.com/learn/encrypted-backup
Language: en
Updated: 2026-10-30

An encrypted backup is a copy of a system's data in which the sensitive content stays encrypted, so that the copy is useless to anyone who obtains it unless they also have keys that are kept somewhere else, and is therefore safe to store in ordinary places such as cloud storage or a second disk.

## The rule that makes it work

A backup is only as protected as the keys that open it. If the database dump and the key that decrypts it sit in the same bucket, the backup isn't encrypted in any meaningful sense; it's packaged. So an encrypted backup has two parts with different handling:

- **The data**, which can be copied widely because it reveals nothing on its own.
- **The keys**, which are kept separately, with fewer copies and stricter access.

For a vault that decrypts on the server, the key part is the server's root key or its unseal shares. For a vault that decrypts only on clients, the server never had the keys to the values in the first place, so a backup of the server holds ciphertext by construction.

## What a backup still reveals

"Encrypted" rarely means "nothing readable". Names of projects and environments, user email addresses, audit logs and sizes and times of changes are often stored in plain form, and they are in the backup too. Treat a vault backup as sensitive metadata even when the values are safe. See [metadata exposure](https://crunu.com/learn/metadata-exposure).

## Restores have side effects

- **Everything after the snapshot is gone.** Values saved since then, access granted since then, revocations since then.
- **Revoked access can come back.** If someone was removed after the snapshot, the restored data includes them again. Re-check removals after any restore.
- **Clients may object.** Systems with [rollback protection](https://crunu.com/learn/rollback-protection) remember the newest state they have seen and refuse older ones, so a restore can look like an attack to them until they are told to accept it.

## Common mistakes

- **Backing up the key with the data.**
- **Never testing a restore.** An archive you have never loaded is a hope, not a backup.
- **Backups that outlive retention rules.** A two-year-old backup holds two-year-old access.

## Backups in Crunu

On a self-hosted Crunu server, `crunu-server export` writes the whole database to an NDJSON archive, optionally compressed, without any plaintext values: environment contents are ciphertext, environment keys are sealed to people's and machines' keys, and passwords and Secret Keys never reach the server.

```sh
node scripts/crunu-server.mjs export --env-file .env --from postgres:env:DATABASE_URL --out backups/crunu-2026-10-30.ndjson.gz
```

`crunu-server verify` checks an archive's integrity, checksum and schema compatibility, and `import` loads it into an empty database. The server's `.env` file, which holds `SERVER_KEY`, is backed up separately in a password manager: never in the same place as the archives, because together they reveal authenticator-app secrets and alert webhook settings. The archive does contain metadata such as names, email addresses and the audit log.

The server has no built-in backup scheduler; the documentation gives a daily cron recipe. After a restore, agents and browsers need to reset what they remember about the server, because of rollback protection. Details are in [backups and restore](https://crunu.com/docs/self-hosting/backups-and-restore), and the wider picture in [self-hosted secrets manager: options and trade-offs](https://crunu.com/guides/self-hosting-a-secrets-vault). For a longer walk-through, see [backing up a vault without plaintext](https://crunu.com/blog/backing-up-a-vault-without-plaintext).