Backup

There are two backups, and neither replaces the other:

	What it covers	How
The product’s Backup	Configuration — projects, connections, variables, alarms, screens, scripts	The Backup screen in the interface, producing a ZIP
Installation backup	Every data store	On the server: copies of the databases and the directories

The first is for moving a configuration or rolling one back; the second is for bringing the installation back after you lose the machine.

The product’s Backup

A backup is scoped to one space. You may optionally pick a single project; without one, the whole space is taken. The output is a timestamped ZIP.

The passphrase and the signature are two different things

Two fields may be asked for, and they are not interchangeable:

Field	What it is for
Passphrase	The archive’s own password. It derives the key that seals the file, it is chosen per file, and it is shared with whoever will restore. At least 8 characters
Signature password	Your own account password, re-entered so the audit record can say who approved the act. It opens no file and is stored nowhere. Optional

Lose the passphrase and the archive will not open

The key that opens the archive is derived from the passphrase, and the product does not keep it. Store the value you choose so that it reaches whoever will restore the file.

Restoring

Restore accepts only a .zip produced by Backup.

The order is deliberate: the archive is read and verified first — a step that touches nothing in the installation — and the signature is produced immediately before the first write. What follows in practice: if the signature is refused, the restore never starts, and you are not left with a half-written installation.

Deleted records come back under their own ids. If you deleted a record and then restore a backup, it returns under its original id rather than as a new record. That matters because its logged values, its fired-alarm history, its row-access anchor and its audit trail are all written against that id — coming back under it keeps the history attached. Creating a new record with the same name does not do that.

Deleted records are not included in a backup; the revival on restore is for the records the file names.

What the ZIP does not carry

• Historian data. Logged values live in the historian database, not in the backup ZIP. Because the backup preserves ids, the history still matches the records after a restore.
• The master key. See below.

Installation backup

To rebuild the machine from nothing you need all of:

What	Why
PostgreSQL	Configuration, users, the audit trail
The historian database	Logged values
Redis	The encrypted secret bundle and working state
./data	The secret bundle’s file copy, and working data
./fs	Uploaded files

Both paths are relative to the working directory; make sure a copy of the installation directory covers them.

The master key is not in the backup

This is the most important thing on this page.

A backup carries the encrypted secret bundle and not the key that opens it. INS_MASTER_KEY is held in nothing the product persists — not the database, not Redis, not secrets.json. Whoever restores a backup must therefore already know it, and there is no rotation path: it is chosen once, at installation.

Record it outside the product on the day you install

A password manager, or a sealed envelope in the plant safe. With a backup but without the key, the encrypted fields and the signature records cannot be recovered.

The two ways a restore fails — one of them silently

The bundle came back and the key is wrong or absent → the application does not start. The bundle cannot be decrypted and the installation refuses to run. Nothing is damaged and nothing is quietly wrong; it simply will not run until the right key is supplied. Trying to change INS_MASTER_KEY on a working installation does the same thing.

The bundle never came back → the application starts, and is quietly broken. With an empty Redis and no secrets.json, the product finds no bundle, generates a fresh one under whatever master key it was given, and boots normally. Every value the old attribute key protected then reads back as empty, and the code-integrity stamps no longer match. The screens come up, but the installation cannot connect to a device, send mail or send an SMS — and none of it looks like it has anything to do with a restore.

Check the bundle after a restore

Before calling a restore successful, confirm the secret bundle actually came across: the bundle key should be present in Redis, or ${ins.data.path}/secrets.json should have been copied. A clean-looking start is not a substitute for that check.

What losing each key in the bundle costs

Key	If it is lost
Attribute encryption	Every value stored encrypted stops decrypting — the LDAP bind password, mail and SMS provider credentials, custom datasource passwords, the map and weather API keys, and the sensitive protocol fields inside a connection’s configuration. None was ever stored in plaintext, so none can be recovered; each has to be entered again by hand
Code integrity	The stamps over stored user code (scripts, expressions, custom alarm conditions, animation and faceplate elements, report datasources) no longer verify. In warning mode that is a security line on every read; in enforcing mode the code does not run
Electronic signature	The one loss nothing repairs. Every signature already recorded becomes unverifiable, because a signature can only be recomputed under the key that made it. What is lost is not the data but the evidence that a person approved it, and no backup reconstructs it
Session key	Harmless: every session drops and everyone signs in again
Cluster key	Nodes stop trusting one another until they are all on one bundle again

Related

• Configuration — the master key and the environment variables
• Redundancy