Note
Scheduled station backups, and the gap
Niagara ships scheduled backups for the stations a Supervisor watches over. The Supervisor itself is the exception — and it is the host holding the histories, the graphics and the hierarchy.
- Backups
- Provisioning
- Supervisor
"Backup" means three different things
Before scheduling anything, be precise about which of these you mean, because they restore differently and are not interchangeable.
| Kind | Contains | Restores to |
|---|---|---|
| Station copy | The station database, histories and alarms. | Any host, including a different controller model. The portable one. |
| Backup distribution | The above plus references to modules, the runtime and OS version, and platform configuration. | A host you are rebuilding to match. Downgrading needs a clean distribution first. |
| Clone | Everything, including copies of the modules, the runtime, the OS image and the platform configuration. | The same model of controller only. Self-contained, and much larger. |
What is scheduled out of the box
A Supervisor's Niagara Network carries a provisioning extension, and that extension has a schedule component wired to a start-backup action. Set the schedule and every station in the network is backed up together, without anyone opening Workbench.
Provisioning does considerably more than backups — installing software, updating licences, distributing certificates, changing default credentials, applying templates and running custom jobs — all driven from the Supervisor against the stations beneath it. If you are only using it for backups you are using a small corner of it.
The built-in schedule does not scale. Niagara's own documentation advises against it on a larger enterprise system, because it fires a backup of every subordinate station at the same moment. On a sizeable estate, use job prototypes so the work is batched and staggered instead.
The gap
All of that provisioning work is performed by the Supervisor against the stations in its Niagara Network. Its own station is not one of them.
Which is awkward, because the Supervisor is usually the host that matters most: the consolidated histories, the graphics, the hierarchy, the users, the reports. A site can have every controller backed up nightly and the single most valuable station on the estate backed up whenever somebody last remembered.
That gap is why a market exists for third-party scheduled-backup modules, some priced in the thousands. It is a genuine hole, and paying to fill it is a legitimate answer — but it is worth knowing you are paying for one missing schedule rather than for backup as a capability.
What to put in place
- Schedule the subordinates properly — job prototypes rather than the convenience schedule, staggered, with the results actually reviewed.
- Decide explicitly how the Supervisor gets backed up. A third-party module, a scheduled job that drives the backup, or a documented manual procedure with an owner and a date. Any of the three beats the usual answer, which is silence.
- Get the files off the host. A backup stored only on the machine it protects is not a backup.
- Restore one, once. Onto spare hardware, before you need it. An untested backup is an assumption with a filename.
Related
Where this comes up in the work
Station engineering
Niagara station and controller setup end to end: platform commissioning, TLS, users and roles, BACnet and Modbus, tagging, histories, alarms, backups.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
More notes
Other things worth writing down
Which Niagara version to stamp a module for
A module's declared dependency version is a floor, not a pin. Build against the newest SDK you have and stamp for the oldest station it has to load on.
- Module development
- Mixed estates
- Build tooling
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
Pure Java, or it will not run on a JACE
A controller is an ARM host with a fraction of a server's memory. Native libraries, JNI and heavyweight dependencies do not survive the move from a PC.
- JACE
- Controllers
- Module development
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.