PLC and SCADA backups you can actually restore

A PLC or SCADA backup is only useful if the saved version matches what is running in the field, includes the network configuration, licences and engineering software version, and has been restored successfully in a test.

Most sites have backup files. Far fewer have backups they can restore at three in the morning when a CPU or a SCADA server dies. This guide covers what a complete backup contains, why restores fail, how to prove a copy matches the running system, how to test a restore and how often to save. It builds on the SCADA architecture guide, because every layer in that chain needs its own copy.

A control system backup is a set of files, not one file. Each layer of the system holds something the others cannot rebuild.

The PLC program is the obvious part. Just as important are the HMI and SCADA project, the tag database, the historian and any application database, the configuration of gateways and converters, and the network settings that let them find each other. Firmware versions, licences and the exact engineering software version decide whether those files can be opened at all. Documents such as the I/O list, topology drawing and change records explain how the pieces fit.

Citia's PLC/SCADA assessment material makes the same point: PLC programs, gateway configurations, databases, SCADA projects and engineering documents serve different roles, so one backup must not be assumed to cover every layer. The grid below is a practical checklist.

Do not forget the small devices. Protocol gateways, serial converters and managed switches each hold settings that took hours to get right, and they are often missing from backup sets because they have no project file of their own.

A backup usually fails for a dull reason: it is old, incomplete or cannot be opened. These problems stay hidden until the day the copy is needed.

The repair of the switchgear monitoring system at Petrokimia Gresik shows several at once. The existing backup could not be downloaded because the controller firmware had been upgraded, so a newer ABB Freelance version had to be installed on the engineering station. On top of that, the old engineering station hard disk had failed, so the last program was no longer available, and the system had to be reviewed and re-programmed. See the Petrokimia Gresik recovery.

Other common causes are just as ordinary:

• the saved copy is older than the program running in the field;
• the only copy sits on the engineering PC that just failed;
• nobody recorded which software version opens the file;
• the licence was tied to a dongle or PC that no longer exists;
• gateway and converter settings were never saved at all;
• the copy was taken while a forced value or test mode was still active.

At Mayora in Cianjur, the lessons recorded after a chiller SCADA repair included that backups of PLC and SCADA configuration help recovery. See the Mayora chiller SCADA repair.

A restore test proves that a copy can rebuild a working system. It does not need to touch the running plant.

Use a spare CPU, a test rack or a virtual machine for the SCADA server. Install the engineering software version recorded in the register, restore the files, and check that the program opens, compiles and matches the online version. For SCADA, confirm that graphics load, drivers start and tags resolve. Write down every gap, such as a missing licence or driver, and fix it in the backup set, not only on the test machine.

The US Cybersecurity and Infrastructure Security Agency (CISA) makes the same point in its 2025 guidance on operational technology: software backups and standby systems should be tested routinely, so that manual operation is possible and safe during an incident.

Schedule restore tests like any other maintenance task, at a fixed interval agreed for each critical system and after every major software upgrade. A test that is planned gets done; one that waits for a quiet week does not.

Back up whenever something changes, and on a fixed routine in case a change slipped through. The trigger matters more than the calendar.

The table links common events to what should be saved. The routine interval depends on how often the site changes; at the Padalarang fuel terminal, for example, the TAS maintenance team makes a database backup on the server during each monthly visit. See the Padalarang TAS lifecycle support.

Backups need a named owner on site, even when contractors do the work. Without one, each contractor keeps its own copy and nobody holds the complete set. When a contractor finishes a job, ask for the final program, the changed configuration and the comparison result as part of acceptance, before the work is signed off.

Put backup duties into maintenance contracts: what is saved, how often, where, and how restores are tested and reported. Citia's Condition Monitoring and Maintenance service includes backup and restore tests and delivers a backup register with updated configuration. The PLC/SCADA assessment guide explains why a backup needs its recovery context recorded alongside it.

Good backups also make other work safer. They are the first step in safe PLC troubleshooting, and they are the starting point for any plan to replace hardware that has reached the end of vendor support, covered in obsolete PLC and SCADA: repair or migrate.