Moving to another server

A backup restores this deployment. A configuration bundle carries a configuration. Moving to another server is the third job: putting the whole deployment — the same encryption key, the same accounts, the same alert history — onto a different machine.

It is one screen: Settings ▸ Move to another server. Type the new server’s address and an account to sign in as, press the button, and watch it work. If that machine has no Docker, Yagra installs it there.

What it moves

Carried: the encryption key (and the session and bus keys beside it), the whole PostgreSQL database — nodes, groups, thresholds, users, alert history, the audit log — the metrics, this deployment’s .env and composition including any local overrides, and, if you tick them, the event and flow stores and the three Yagra images.

Not carried: Redis, which is a mirror of the database; the certificate files on disk, which are rebuilt from their database rows on the first start; core’s rotated logs; and the poller’s send buffer.

The version is pinned to whatever the old server was running. Upgrade afterwards, from the new server’s own Settings ▸ Upgrade.

What the new server needs

• Linux on x86-64 with sh, tar and an SSH daemon.
• Docker with the docker compose v2 plugin — or sudo and internet access, so Yagra can install it with the official script.
• Nothing of Yagra’s on it already. The restore refuses a host that already carries Yagra volumes or containers. It never replaces, merges with, or upgrades an existing deployment.

The archive holds every secret

The file it builds contains the encryption key and the database together. Anyone who has it can read every SNMP community, every device login, every API token and every notification secret the deployment stores. Treat it exactly as you would the encryption key, and delete it from every machine it passed through once the move is done.

For that reason the whole screen is Admin-only and needs three permissions at once, and both building the archive and downloading it are written to the audit log.

Carrying it yourself

If Yagra should not be given SSH access to the new server, press Build the archive instead, download it, and run three commands there:

mkdir yagra && cd yagra
tar -xzf ~/yagra-relocation-<stamp>.tar.gz
./yagra-relocate.sh

Docker has to be installed already on that route. Everything else is the same, including the checks the script runs before it declares success.

After it succeeds

Five things it cannot decide for you:

1. Stop the old server. Until you do, two deployments are polling the same devices and both will notify.
2. Reconnect the remote sites, if you run distributed pollers and the address changed. This is the longest step — see below.
3. OIDC redirect URIs still point at the old host.
4. Devices sending syslog, SNMP traps or flow records to the old address need repointing.
5. The firewall on the new server, if it runs one: open the WebUI port.

The WebUI’s certificate is still the old host’s, so browsers warn until it is replaced.

Reconnecting remote sites

Remote pollers do not follow the move. Each one dials an address written in its own .env and pins a certificate in its own directory, and the new server can change neither: the only channel it has to a site is the bus, which is exactly what stops working when the address changes.

In the new server’s WebUI, in this order:

1. Settings ▸ Pollers ▸ Reissue certificate… with the new address. This stores a new certificate, but the bus keeps serving the old one — it reads its certificate at startup — and the panel tells you so.

2. Make it take effect by pressing Stop accepting and then Accept remote pollers with the new address. Monitoring pauses briefly each time. Skipping this hands the sites a certificate the bus is not serving, and they fail to connect with nothing visible centrally.

3. Issue each site’s bundle again, naming the new address. It carries the certificate now in use and a fresh token; the previous token stops working.

4. Install it at the site, over the directory already there, and recreate the poller:

   cd ~/yagra-poller
   tar -xzf ~/yagra-poller-<id>.tar.gz -C ~/yagra-poller
   docker compose -p yagra-poller -f docker-compose.poller.yml up -d --force-recreate

Each poller reappears within about ten seconds. Online is not the same as polling: watch the Working set and Results columns on Settings ▸ Pollers until both move.

If it fails

There is no rollback and none is needed. A relocation either produced a working deployment on the new host or produced nothing at all: a refusal writes nothing there, and a failure part-way is cleared by removing what was made and running it again.

To confirm at any time that the secrets came across, ask the new deployment:

docker compose -p yagra -f docker-compose.deploy.yml exec -T core yagra-core verify-secrets

One line of JSON: how many sealed secrets it holds, and how many its key can open. A gap between the two is the one failure a restore can otherwise hide, because everything else looks healthy until the next poll.