In a large system with many controllers connected to a single Supervisor, invoking the action to backup all stations (or equivalent steps listed) creates a provisioning job that can take an excessive amount of time to complete and can put an undue load on the system, especially if an administrator invokes it at a peak time. Finally, unlike a provisioning job from a NiagaraNetworkJobPrototype, which is the preferred backup method, the accumulated backup .dist files remain stored on the Supervisor until manually deleted. These files are not controlled by job retention policies. Without manual intervention, over a long period of time this could lead to a disk-full condition on a Supervisor.

For a large enterprise system where a Supervisor has many controllers, backing up is better accomplished by adding multiple NiagaraNetworkJobPrototype components in the Supervisor’s station. You copy the components from the provisioningNiagara palette. Then you can configure each one for a custom backup job, selecting some of the system’s host stations in each component.

To run each backup job at some periodic interval, perhaps at an off-hours time, you could add and link to a standard TriggerSchedule component (also available on the provisioningNiagara palette). You set up multiple TriggerSchedules, one configured slightly differently for each linked NiagaraNetworkJobPrototype. Using this method, you could constructively stage multiple backups in sequence—say 10 minutes apart from one another.

Additionally, each NiagaraNetworkJobPrototype component has job retention policies, which you can configure via its Prototype Job List view. You can (and should) configure them to provide automatic disposal of older saved backup .dist files, based on age or some number of earlier saved backup .dist files. For an example procedure including NiagaraNetworkJobPrototypes, see “Prototype jobs” in Chapter 3.