Skip to main content

Updates & Backups

Image updates​

Watchtower ships in every node stack and polls every 5 minutes, rolling-restarting the node when a new image is published. On a normal day there is nothing to do.

To force an update immediately:

cd node-deploy/testnet/validator      # or testnet/rpc, testnet/indexer-rpc
docker compose pull && docker compose up -d

Check what Watchtower has been doing:

docker compose logs orbinum-watchtower
Watchtower is configured to revive stopped containers

It runs with INCLUDE_STOPPED, REVIVE_STOPPED and INCLUDE_RESTARTING on purpose. A release once shipped a binary without its executable bit, leaving nodes in created/restarting — states a default Watchtower ignores entirely, so the fix could not reach them.

Runtime upgrades are different: they apply through on-chain governance and need no operator action. The node adopts the new runtime when the upgrade block finalizes.

Config changes need a recreate​

A container's command line is fixed at creation. docker compose restart brings the node back with its old arguments, so an .env edit appears to do nothing.

docker compose up -d --force-recreate

Verify the running command actually changed:

docker inspect orbinum-validator --format '{{join .Config.Cmd " "}}'

Back up your keystore​

Chain data lives in a named Docker volume and can always be resynced. The keystore cannot. It holds the private halves of your session keys — and, if you relay, the evmr key backing your registered relay address.

docker cp orbinum-validator:/data/chains/orbinum_testnet/keystore ./keystore-backup
tar -czf keystore-$(date +%Y%m%d).tar.gz keystore-backup
gpg --symmetric --cipher-algo AES256 keystore-*.tar.gz
rm -rf keystore-backup
Never run two nodes with the same keys

Restoring this backup onto a second machine while the first is still running makes both sign with the same identity. On Orbinum that costs you nothing today — there is no slashing — but it produces conflicting votes that damage finality for the whole network, and it is exactly what slashing will punish once it exists.

If you are migrating, stop the old node first and confirm it is stopped.

Losing the keystore is recoverable: generate new session keys with author_rotateKeys and submit session.setKeys again. You keep your slot in the approved set; you just miss blocks until the next session rotation.

Database maintenance​

Pruning is set by flag, not by a maintenance job — see Node Flags. RPC and indexer nodes run --state-pruning archive, so their disk grows without bound; that is the constraint the sizing table calls out for the archive role.

A full reset is a last resort:

docker compose down -v      # deletes the volume — full resync, and the keystore