The short answer
What to Back Up in a Control System
A control system backup covers everything needed to rebuild the system from bare hardware: controller projects with firmware versions and retentive data, SCADA and historian servers as images and as exported projects, HMI panel projects, drive and analyzer parameters, switch, firewall, and radio configurations, software installers and license files, credentials in a managed store, and the drawings and narratives that explain it all. Each item has a change frequency that sets its backup interval, at least one copy offline, and a restore that has been tested.
Key points
- If it has a configuration, it needs a backup. Switches, radios, drives, and analyzers included.
- A server image and an exported project are different backups. Take both.
- Installers and license files are part of the backup. A project file with no software to open it is not restorable.
- Set the interval from how often it changes: after every change, and on a schedule regardless.
- One copy offline, one copy off site, one restore test a year.
The test
The question that defines the list is simple: if this device or this server were destroyed tonight, what would be needed to put a working replacement in service tomorrow? Everything in that answer is on the backup list. Utilities that have rebuilt after ransomware or a lightning strike report the same discoveries: the controller program was backed up but not the firmware version, the SCADA project but not the license, the historian but not the driver configuration, the drive parameters not at all. The list below is the answer for a typical utility.
The inventory
| Item | What it contains | Changes | Interval |
|---|---|---|---|
| Controller projects | The program with comments, the I/O configuration, tags, and the firmware version | With every program change | After each change; monthly compare and backup |
| Controller retentive data | Setpoints, tuning, calibration factors, totalizers, alternator states | Continuously in operation | Weekly export where the platform allows; at minimum before and after any change |
| SCADA server image | The operating system, the SCADA software, drivers, and configuration as a restorable disk image | With patches and configuration | Monthly, and before any update |
| SCADA project export | Displays, tags, alarms, scripts, users, and reports as the platform export | With every configuration change | After each change; weekly |
| Historian data | The archive of process data | Continuously | Daily incremental; the retention policy sets how far back |
| Historian configuration | Tag collection lists, compression settings, calculations | Occasionally | With the SCADA project |
| HMI panel projects | The runtime project for each local panel | Occasionally | After each change; the panel file and the development file |
| Drive parameters | Every parameter of every drive and soft starter | Rarely after commissioning | At commissioning, after any change, and annually |
| Instrument and analyzer configurations | Ranges, trims, calibration data, analyzer settings | At calibration | With the calibration record |
| Network device configurations | Switch, router, firewall, and radio configurations, including VLANs, rules, and addressing | Occasionally | After each change; quarterly |
| Gateway and protocol converter configurations | The mapping tables | Occasionally | After each change |
| Software installers and licenses | The exact versions of the programming software, the SCADA software, drivers, and the license files and activation records | With each version | When acquired; kept forever |
| Credentials | Every device and account password, in a managed store with its own backup | When changed | The store handles it; export a sealed copy off site |
| Documentation | Drawings, I/O list, instrument list, narratives, network drawing, register maps | With each change | With the project record |
| Server and workstation builds | How each machine was built: partitions, drivers, settings, the steps | Rarely | A build document, updated when the build changes |
Two kinds of server backup
A SCADA server needs both an image and an export. The image restores the whole machine, operating system and all, onto the same or similar hardware in an hour, and it is the fastest path back after a disk failure or a ransomware event. The export restores the SCADA configuration onto a freshly built machine of any generation, which is what is needed when the old hardware is gone or the image will not boot on new hardware. The image is taken by a backup tool on a schedule; the export is taken from the SCADA software after each change. A utility that has only images discovers after five years that the image will not restore onto anything it can buy.
Where the copies live
- The working copy
- On the engineering workstation or the SCADA server, where the software uses it. Convenient, and the first thing lost.
- The repository
- A version-controlled store on a server in the engineering zone, holding every version of every project and configuration with who changed it and when. The reference copy.
- The offline copy
- An external drive or media, written on a schedule, unplugged, and stored in a locked cabinet. Rotated so that two generations exist.
- The off-site copy
- A second offline copy at another utility facility, or an immutable cloud store. Protects against fire, flood, and theft at the plant.
The restore test
A backup that has never been restored is an assumption. Once a year, restore a controller program to a spare controller, a SCADA export to a test machine, a drive parameter set to a spare drive, and a switch configuration to a spare switch, and time each one. The test finds the missing firmware file, the expired license, the installer that no longer runs on a current operating system, the export that was taken from the wrong project. Each finding is fixed and the test is repeated. The record of the test, with the dates and the times, is what an auditor asks for and what the utility relies on the day the plant is dark.
Ownership
Every item on the list has a person who takes the backup and a person who checks that it was taken. At a small utility that is one person and their supervisor, with a checklist on the wall. At a larger one it is a schedule in the maintenance system with a work order per backup. The failure mode is the same at any size: the backup was somebody's job until they left, and nobody picked it up. The list, the schedule, and the owner are the program.
Frequently asked questions
- How long should backups be kept?
- Configuration backups, every version, forever; they are small and a five-year-old version answers questions. Server images, a few generations. Historian data, per the retention policy the regulator and the utility set, often years for compliance data. Credentials, current plus the last, in the store.
- Should the backups be encrypted?
- The off-site and cloud copies, yes, with the key stored where the restore team can reach it without the systems that were lost. The offline drive in a locked cabinet is protected by the lock; encrypting it too is reasonable if the key management is real.
- What about the vendor packaged systems?
- A membrane skid, a generator controller, an on-site generation system: each has a controller and an HMI with configurations the vendor may consider proprietary. The contract requires that the utility receives a backup at handover and after every vendor change, in a form the vendor can restore, and the utility keeps it with the rest.
- Can the integrator keep the backups for us?
- The integrator keeping a copy is good; the integrator keeping the only copy is not. The utility owns the system and holds its own backups, and the integrator copy is the off-site one. An integrator who goes out of business, loses a laptop, or ends the relationship takes the only copy with them.
Related topics
- PLC Program BackupsWhat a complete controller backup contains, how often to take one, where to keep it, why the upload from the running controller is not the master, and the verification that turns a folder of files into a recovery plan.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- Small Utility Cybersecurity PrioritiesWhat a utility with a few operators and no IT department should do first: the ten measures that remove most of the risk for the least money and time, in the order to do them, with what each one costs, what it prevents, and how to know it is done.
- HistoriansWhat a process historian does that a database does not, how data gets into it, how compression and retrieval work, how to size and keep it, and the settings that quietly throw data away.
- SCADA RedundancyWhat redundant SCADA servers protect against and what they do not, how failover works for tags, alarms, history, and clients, the network and controller layers beneath it, and why an untested failover is not redundancy.
- SCADA BackupsWhat a SCADA backup must contain to bring a system back: the project export, an image of each server, the databases, historian archives, licenses, certificates, scripts, and network device configurations, with frequency, retention, and the restore procedure.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.