Backup and Restore
Back up the state store and the secrets directory separately, and restore a guardian onto a new host.
What to Back Up
A guardian has two things to back up:
| Backup | What it holds | Where to keep it |
|---|---|---|
| The state store | Two databases: the identity service's store, and the guardian's record of every realm, machine, renewal, account change and control action. Every key in it is sealed. | In one custody, on a schedule |
| The secrets directory | The deployment's whole configuration: the settings, the realm credential, every generated secret, the key that seals the state store, and the internal certificate authority. | In a different custody from the state store |
Never keep the two backups together. A backup that holds both the state store and the keys that protect it is a single point of compromise.
The metrics store needs no backup. Machines send their telemetry again, so losing it costs history, not state.
Backing Up the State Store
On a schedule, take a compressed full dump of every database in the state store. The deployment guide in the guardian checkout, docs/deployment.md, gives the command in its Backup section.
The dump holds:
- Every realm and sub-realm, with its delegation and its sealed root key.
- Every machine, with its sealed secrets and its renewal history.
- Each admin node's sealed identity.
- The control record, and the sealed record of where each machine was moved.
- In standalone mode, the operators' accounts and the record of every change to them.
Backing Up the Secrets Directory
Copy the whole secrets/ directory to a different custodian from the one that holds the state store. Everything the stack takes from the host lives there and nowhere else.
| If you lose | What happens |
|---|---|
guardian_seal_key | Everything sealed in the state store becomes unreadable: the realm and sub-realm keys, every machine's secrets, the admin nodes' identities and the compartment moves. |
| The internal certificate authority | Every service certificate is issued again. With an internal certificate, operators and machines must trust the new authority. |
guardian_credential | Only VeilNet can issue you another. |
.env | You lose your settings, and setup starts again from .env.example. |
If you have run setup with --force, the directory also holds .env.<time>.bak files with the settings each run replaced. Treat them as you treat .env.
Restoring a Guardian
Restore onto a new host that answers on the same address, because every machine renews against the address in its manifest.
In a guardian checkout, copy in the anchor binaries:
$ cp anchord-linux-amd64 anchorctl-linux-amd64 ./bin/
- You can sign in, and the dashboard shows the realm credential and the fleet as they were.
- Telemetry shows in-band
runningin every realm. The admin nodes come back with the identities they had.
Test a restore on a spare host before you need one.