Appearance
Restore
Restoring is the inverse of Backup. The home directory is portable: drop a backup back into place, run hivecast seed to rehydrate the bundled package store, then hivecast start.
When to restore
- After a failed upgrade.
- After hardware migration to a new machine.
- After a corrupted disk.
- After a Device Link mistake (you want yesterday's link record back).
Procedure (.deb / systemd install)
bash
# 1. Stop services so nothing writes to /var/lib/hivecast.
sudo systemctl stop hivecast-host.service hivecast-nats.service
# 2. Move the broken home aside (do not delete until restore is verified).
sudo mv /var/lib/hivecast /var/lib/hivecast.broken-$(date +%s)
# 3. Restore the backup tarball.
sudo mkdir -p /var/lib/hivecast
sudo tar -xzf hivecast-backup-YYYYMMDD.tar.gz -C / \
--strip-components=2 # adjust based on tarball layout
# 4. Fix ownership.
sudo chown -R hivecast:hivecast /var/lib/hivecast
# 5. Remove volatile files that should not be in a backup but might be.
sudo rm -f \
/var/lib/hivecast/host.status.json \
/var/lib/hivecast/host.pid \
/var/lib/hivecast/host.start.lock
sudo rm -rf /var/lib/hivecast/runtime-env
# 6. Re-seed the bundled package store. Idempotent.
sudo -u hivecast hivecast seed --home /var/lib/hivecast | jq .
# 7. Re-drop the bundled NATS binary if missing.
[ -x /var/lib/hivecast/bin/nats-server ] || \
sudo cp /opt/hivecast/dist/bin/nats-server /var/lib/hivecast/bin/
# 8. Start NATS first, then the Host (Requires= dependency enforces this).
sudo systemctl start hivecast-nats.service
sudo systemctl start hivecast-host.service
# 9. Verify.
sudo systemctl status hivecast-host.service hivecast-nats.service
sudo -u hivecast hivecast status --home /var/lib/hivecast | jq '.status'
sudo -u hivecast hivecast runtimes --home /var/lib/hivecast | jq '.runtimes | length'If hivecast seed reports runtimeRecords.corrupt non-empty, deal with it now (typically: delete the named directories and re-create the runtimes via matrix up). The Host will not silently respawn from a corrupt record, but it will attempt to bootstrap healthy ones around it (parse-and-skip, projects/matrix-3/packages/host-service/src/host-state-store.ts:106-142).
Procedure (wrapper / per-user install)
bash
HOST_HOME=/path/to/host-home
hivecast stop --home "$HOST_HOME" 2>/dev/null || true
mv "$HOST_HOME" "${HOST_HOME}.broken-$(date +%s)"
mkdir -p "$HOST_HOME"
tar -xzf hivecast-backup-YYYYMMDD.tar.gz -C "$(dirname "$HOST_HOME")"
rm -f \
"$HOST_HOME/host.status.json" \
"$HOST_HOME/host.pid" \
"$HOST_HOME/host.start.lock"
rm -rf "$HOST_HOME/runtime-env"
hivecast seed --home "$HOST_HOME" | jq .
hivecast start --home "$HOST_HOME"
hivecast status --home "$HOST_HOME" | jq .
hivecast runtimes --home "$HOST_HOME" | jq '.runtimes | length'Cross-machine restore
The home directory is not machine-keyed. You can restore a backup made on machine A onto machine B and the Host will start. The installId and hostId carry over, which is the right behavior: the same Device should remain the same Device after a hardware swap.
What does NOT carry over:
- The exact NATS pid (recomputed).
- The exact HTTP port (re-allocated unless pinned in
host.json). - The exact
hostNatsStatusURL (rebuilt fromhost.json).
If you want to fork a Host (one becomes two), regenerate credentials/hivecast-install.json on the new home before its first start. Otherwise both Hosts will heartbeat the same installId to HiveCast, which is wrong.
Verifying after restore
bash
# Did the Host start cleanly?
sudo journalctl -u hivecast-host.service -n 100
# Are runtimes healthy?
sudo -u hivecast matrix invoke host.control runtime.list '{}' \
| jq '.runtimes[] | { id: .runtimeId, status, ch: .metadata.controlHealthStatus }'
# Did the Device Link survive?
sudo -u hivecast hivecast link-status --home /var/lib/hivecast | jq .If the Device Link reports linkStatus: "stale", the cloud has not seen a heartbeat from this Host recently. Wait one heartbeat interval (15s) and recheck; if still stale, see Diagnostics.