The short answer
PLC Program Backups
A PLC program backup is the complete set of files needed to restore a controller to its current state: the project with comments and documentation, the firmware version, the configuration of every module and communication card, the retentive data and setpoints, and the parameters of attached devices. It is taken after every change and on a schedule, stored in at least two places including one offline, compared with the running controller to detect drift, and proven by an actual restore to a spare controller.
Key points
- The backup is the project file with its comments, not the upload from the controller.
- Firmware version, module configuration, setpoints, and device parameters are part of it.
- Take one after every change, and compare on a schedule to catch changes nobody recorded.
- Two copies, one offline. A backup on the engineering laptop is one theft from gone.
- Restore one to a spare controller once a year. That is the test that matters.
What a backup is for
A controller fails, is destroyed by lightning, is ransomed, or is quietly modified. In every case the utility needs to put a known-good program back on a controller, quickly, with confidence that it is the right one. The backup is what makes that possible. It is also the reference against which the running controller is compared to find changes that were never recorded, which makes it a security control as much as a maintenance record.
What a complete backup contains
| Item | Why it is needed | Where it is often missed |
|---|---|---|
| Project file with comments, tag descriptions, and documentation | The program someone can read and maintain | An upload from the controller without the offline project loses comments on many platforms |
| Firmware version of the processor and every module | A project built for one firmware may not download to another; a replacement controller must be flashed to match | Recorded nowhere; discovered when the download fails |
| Hardware configuration: rack, modules, communication cards, network settings | A restore onto a replacement needs the same configuration | Usually in the project; IP addresses and switch settings often are not |
| Retentive data: setpoints, tuning, calibration factors, totalizer values | The program without its setpoints runs the plant wrong | Not part of the program file on most platforms; needs a separate export |
| Attached device parameters: drives, analyzers, HMIs, radios | A restored controller talking to devices on defaults does not run the plant | Each device has its own backup tool and format |
| The programming software version and any license files | A ten-year-old project may need a ten-year-old tool | The installer is gone from the vendor site; keep the media |
| The as-built drawings and the control narrative | Context for the program | Stored somewhere else, if at all |
When to take one
- After every change, before the engineer leaves the site. The change record references the backup.
- On a schedule regardless of changes, monthly at most sites, to catch changes made without a record and to prove the process still works.
- Before any firmware update, any hardware replacement, and any vendor visit.
- Before and after commissioning of anything that touches the controller.
Where to keep it
At least two copies in two places, one of which is offline or otherwise unreachable from the network where ransomware would run. A common arrangement is a version-controlled repository on a server in the engineering zone, a copy pushed to the DMZ file server for the enterprise backup system to collect, and a periodic export to removable media stored in a locked cabinet. The engineering laptop is a working copy, never the only copy; laptops are lost, stolen, and reimaged.
Version control, whether a purpose-built tool for controller projects or a general-purpose repository, records who changed what and when, keeps every previous version, and makes the comparison between versions easy. The purpose-built tools also automate the upload-and-compare against the running controller, which is the change detection function.
Comparison and change detection
A backup that is compared against the running controller on a schedule finds two things: changes that were made and not recorded, and changes that were made by someone who should not have. Both are findings. The comparison uses the platform compare tool or the version control product, and the result is either identical, or a list of differences that each need an explanation. An unexplained difference is treated as an incident until it is explained. The controller mode, its program checksum, and its last-edit timestamp are also readable status values that the SCADA system can alarm on between comparisons.
Proving it
- 1
Pick a controller and a spare
A spare processor of the same model, on the bench, with the modules or a simulator.
- 2
Flash the firmware
To the version recorded in the backup. Note how long it took to find the firmware file.
- 3
Download the project
From the backup store, not from a laptop. Note any error and any prompt the person did not expect.
- 4
Load the retentive data and the device parameters
The setpoints, the drive parameters, the HMI project. Note anything that was missing from the backup.
- 5
Verify
Compare the restored controller with the running one. Identical is the goal; every difference is a gap in the backup.
- 6
Record and fix
Time taken, gaps found, gaps closed. Repeat annually and after any change to the process.
A restore test finds the firmware file that was never saved, the license that expired, the software version that no longer installs on a current laptop, and the setpoint export that nobody did. Each of those is cheap to fix on the bench and very expensive to discover during an outage.
Frequently asked questions
- How long should old versions be kept?
- Indefinitely, for controller projects. Storage is cheap and a five-year-old version answers questions about when a behavior changed. Version control keeps them without effort.
- Should the backup be encrypted?
- The offline and off-site copies, yes, because they are portable. The working repository is protected by the engineering zone controls and access permissions. Whatever is encrypted, the key is stored where the restore team can get it without the systems that were lost.
- What about controllers with no offline project, only the running program?
- Upload it now, save it as the master, and document that comments are missing. Rebuild the documentation over time as people touch it. A program with no backup at all is the highest priority item in the backup program.
- Who is allowed to restore a program to a controller?
- The change management process says: a named person, with a change record, with the program verified against the backup store, with operations informed. A restore is a program download, and a program download to a running process is a change with consequences whatever its reason.
Related topics
- 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.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- Controller Memory and AddressingHow a controller organizes its data: data tables and tags, the input and output images, the elementary data types and what they hold, and the naming discipline that keeps a program readable years later.
- Retentive MemoryWhat survives a power cycle in a controller and what does not, how retention is backed up by battery, capacitor, or nonvolatile storage, what should be retentive, and how retained data gets lost.
- Program Will Not DownloadThe software refuses to download, or the download starts and fails. The version, path, mode, memory, and protection problems behind it, and the order to check them in.
- Control NarrativesWhat a control narrative is, what it must contain, how to write statements that can be tested, and how it drives programming, FAT, and the owner’s acceptance.
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.