Skip to content
LabTether

Backup and Restore

Your LabTether hub holds your entire fleet's inventory, configuration, telemetry history, alert rules, incident records, and session recordings. Losing it means rebuilding everything from scratch. A basic backup strategy takes five minutes to set up and saves you from that scenario.

What to back up

Three things matter:

  1. Postgres database — this is the big one. All your nodes, connectors, alert rules, incidents, service overrides, settings, and metric history live here.
  2. .env.deploy — your deployment configuration file. Contains tokens, passwords, encryption keys, and runtime settings. Losing this means guessing at your original configuration.
  3. Persisted artifacts — desktop session recordings and any custom certificates. Optional, but painful to lose if you rely on them.

Backup strategy

Database backups:

Run make db-backup for a one-off backup. Backups are written to ./backups by default as compressed SQL dumps (labtether_YYYYMMDD_HHMMSS.sql.gz).

Schedule this daily at minimum. A cron job calling make db-backup or the underlying pg_dump command is the simplest approach. Keep multiple restore points — at least a few days of daily backups plus a weekly that you hold for a month.

Config snapshots:

Copy .env.deploy to a safe location before making changes or running upgrades. If your deployment uses custom TLS certificates, back those up too.

Recordings and artifacts:

If you use desktop session recordings, back up the recordings volume. These are large and may not be worth the storage cost depending on your retention settings.

Tip: Run a periodic restore drill in a non-production environment. A backup you have never tested restoring is not really a backup — it is a hope.

Restoring

When you need to restore:

  1. Stop writes or isolate the target environment. Shut down the LabTether stack or point it at a fresh database.

  2. Restore the database:

make db-restore BACKUP_FILE=backups/labtether_20260323_030000.sql.gz

Or use the script directly (includes interactive confirmation):

./scripts/db-restore.sh backups/labtether_20260323_030000.sql.gz

  1. Restore filesystem artifacts if needed — recordings, custom certs.

  2. Start the stack and verify:

    • The console loads and you can log in
    • Node inventory is present
    • Terminal and desktop sessions work
    • Alert rules and incidents are intact

Warning: Match the app version to the backup. Restoring a database from an older version into a newer hub should work (migrations run on startup), but restoring a newer database into an older hub can cause schema mismatch errors. When in doubt, restore the database and the matching hub version together.