PLC backups and version control

What to back up (project, online program, retentive data, firmware, HMI and drive parameters), how to keep versions traceable, text export for diffs and a restore test routine.

The real program is the one running in the controller. A good backup lets you restore a failed CPU, compare what changed and prove which version is in operation.

What to back up

Item	Why
Engineering project (archived, with libraries)	Comments, symbols and structure exist only here
Online upload / card image	Proves what is actually running
Retentive data, recipes, setpoints	Lost on CPU replacement if not saved separately
Firmware versions	Needed to restore the same behaviour
HMI/SCADA projects, drive and device parameters	Often forgotten — a replaced drive without parameters stops the line
Network data	IP plan, device names, switch configs

Version control

One version ID per release: date + increment, recorded in the program (a constant visible on HMI) and in the archive name.
Change log: what, why, who, approved by whom.
Use Git or a vendor version-control system for exported sources (structured text, PLCopen XML, TwinCAT/CODESYS text files, SimaticML/Openness exports). Binary project archives belong in the same repository or a versioned store, not on personal laptops.
Compare before downloading: online vs offline comparison in the engineering tool, or text diff of exports.

Restore test

At least once a year (and after major changes) restore a backup onto a spare CPU or simulator and check that it compiles, downloads and runs. A backup that was never restored is a hope, not a backup.

Connections

Open in Knowledge Graph →

Loading the map…

Sources

Updated 2026-10-04