Backup and restore#

The SQLite database and file-library directory are the durable board data. Protect both, along with the deployment configuration.

Create a backup#

Prerequisites#

Know the active database path.
Have enough protected storage for the database and files/.
Prefer a maintenance window for a simple file copy.

For an online backup, use SQLite's backup mechanism. For a file-level backup, stop Nodehouse first, copy the database together with any SQLite sidecar files, copy files/, then restart the service.

Record the Nodehouse version, database filename and backup timestamp. Existing installations may still use a legacy database filename; back up the file the running health check actually opens.

Restore#

Stop Nodehouse.
Preserve the failed or current data directory separately.
Restore the selected database and file library to persistent storage.
Confirm NODEHOUSE_DB_PATH names the restored database when explicitly set.
Start one service instance.
Check /healthz, the browser terminal and Telnet banner.
Sign in as SysOp and inspect callers, messages, mail and recent calls.

Verify#

Periodically restore a backup into an isolated nonpublic environment and run the smoke check. A backup that has never been restored is not a tested recovery plan.

If it does not work#

Symptom	Check	Recovery
The restored board starts on an empty database	Which data path the revision resolved	See The wrong database opened after an upgrade
The database restores but the file library is missing	Whether both were captured	They are separate; a database-only backup is not a complete one
The smoke check fails on a restore	Whether it passes on the live board	A backup that fails its restore test is not a recovery plan — fix it before you need it
You have never restored a backup	—	Restore one into an isolated nonpublic environment now, not during an incident