PLC Backup Software: What to Back Up, How Often, and How to Prove a Restore Works

PLC backup software uploads the program or configuration that is actually running in each automation device on a schedule, keeps every upload as a version, and tells you when the latest one differs from the last. It is the first and most valuable piece of automation change management, because every other capability, compare, change control and recovery, depends on having a current copy.

The name undersells the job. A useful backup covers far more than PLCs, and the hard part is not taking the copy. It is proving that the copy can be put back. This page covers what to back up, how often, where to store it, what a tested restore looks like, and the tools that automate the work.

What to back up: more than the PLC

Most plants that believe they have backups have the PLCs covered and little else. The devices below each hold logic or configuration that a line cannot run without, and each one fails in its own way.

Asset	What to capture	Suggested frequency	Commonly missed detail
PLCs and safety controllers	The program as uploaded, with tag values where relevant, plus the offline project with comments	Daily for critical lines, and after every change	An upload often lacks comments and descriptions; keep the offline project too
HMI terminals	Runtime application and the source project	Weekly and after changes	Runtime files may not convert back into an editable project
SCADA and historian servers	Full system image plus the application project and configuration database	Image weekly, application daily	Node-locked runtime licences and certificates
Engineering workstations	System image, installed software releases, licence files	Monthly and after software changes	The exact release of the engineering tool each project needs
Robots	Programs, system variables, calibration and tool data	Weekly and after teaching	Mastering and calibration data, without which programs drift
Drives and servo	Parameter sets and motion configuration	After commissioning and changes	Drives replaced under warranty arrive with factory defaults
CNC controls	Part programs, machine data, offsets	Weekly	Machine data set by the OEM and never copied
Switches and firewalls	Running configuration	After changes, and monthly	VLAN and ring settings that only the network vendor tool shows

The panel PCs deserve particular care. On a warehouse recovery we wrote up in a case study, backups were partly in place, and the advice for the panel PCs went well beyond copying files: live image-level backups with bare-metal restore, BitLocker recovery keys saved before any imaging, and a record of node-locked runtime licences. A file copy of a Windows HMI is not a way to rebuild one.

How often to back up PLCs

Frequency is a decision about how much change you are willing to lose. A weekly upload means a week of online edits could vanish with a failed controller. Scheduled jobs make daily backups cost almost nothing in effort, so the practical limits are network load, device availability and the size of the estate.

A reasonable starting rule:

• Critical production controllers: daily, plus an upload before and after every planned change
• Supporting equipment such as utilities and packaging peripherals: weekly
• Infrastructure such as switches and firewalls: after every change, with a monthly sweep
• Images of PCs and servers: weekly, and before any patching or software upgrade

The upload is also the detector. Each scheduled upload compared with the previous one tells you whether anything changed overnight. That turns backup frequency into change-detection frequency, which is the subject of our PLC version control page.

Where to store the backups

Backups held on the same network as the devices are exposed to the same incident. A ransomware event that encrypts the engineering workstations can encrypt the backup share sitting next to them. CISA’s #StopRansomware Guide makes the same point for any organisation: keep backups offline and encrypted, and test them regularly, because many ransomware variants look for reachable backups and delete or encrypt them. Plan at least three locations.

Copy	Where	Protects against
Working repository	The backup server inside the OT network, often in a site operations zone	Device failure, bad changes, day-to-day rollback
Off-site or central copy	A corporate data centre or a managed cloud repository, replicated on a schedule	Loss of the site server, fire, theft
Offline or immutable copy	Write-once storage, an immutable snapshot, or media disconnected after each copy	Ransomware and malicious deletion

The offline copy is the one most plants lack, and it is the one the PLC ransomware recovery page depends on. Keep the engineering software installers and licence files with it. A backup of a 2011 project is not restorable if the only installer for the right release was on the encrypted workstation.

What a tested restore looks like

A backup nobody has restored is a hypothesis. The restore is a chain, and any broken link fails it.

A practical restore test, run on a spare or test controller, or on the real one during a planned stop:

1. Pick a backup at random, not the one prepared for the test.
2. Open it on a workstation that was not used to take it, with the engineering software release recorded in the backup record.
3. Confirm the firmware the project expects, and that a spare module at that firmware exists or can be flashed.
4. Download, run the machine through its normal sequence, and compare the result with the running version on the line.
5. Record the time it took and every missing piece: a password nobody had, a licence on a dongle, an installer that would not run.

The missing pieces are the output. The first test almost always finds something, and finding it on a Tuesday afternoon is far cheaper than finding it during an outage.

Keep a record with every backup, not only the file. The restore depends on facts that the backup file does not carry, and they are the ones nobody can remember at three in the morning.

Field in the backup record	Why the restore needs it
Device name, location and line	The right file goes to the right controller
Engineering software and release	The project opens only in a compatible release
Firmware of the processor and key modules	A spare at different firmware may refuse the download
Date taken and source (uploaded from the device, or saved from a project)	Shows whether it reflects what was running
Approved or not, and by whom	Separates a known-good version from the latest copy
Licences, passwords and keys needed (stored separately and securely)	Protected or safety projects cannot be opened without them
Last restore test and result	Turns the backup from an assumption into evidence

PLC backup software: the main tools

Facts below come from the vendors’ own pages and are current as of October 2026. Device coverage changes with each release, so confirm your specific models and software versions with the vendor.

Tool	Approach	Device scope	Deployment
AMDT octoplant	Scheduled upload jobs compared against the approved version, with disaster recovery per device or by pattern (amdt.com)	Multi-vendor PLCs, HMIs, robots, CNC, drives, SCADA and network devices; AMDT states support for “180+ industrial device types” (amdt.com)	Mainly on-premises, with agents for separated networks
Rockwell FactoryTalk AssetCentre	Scheduled backups, versioning, compare and audit (Rockwell)	Rockwell controllers, drives and HMIs, with some third-party support	On-premises, on the FactoryTalk stack
Copia DeviceLink	Backs up “on a schedule or on demand” and alerts on detected changes (copia.io)	Siemens, Rockwell and Omron named on the product page; more on its multi-vendor page	Cloud on AWS or private cloud (copia.io); press coverage also cites data-centre and air-gapped options (TNW)
Software Defined Automation	Agent-based automated backup with “one-click restore to any point in time” (SDA)	“Supports 13+ PLC vendors,” per its site	Cloud platform with a “lightweight PLC connectivity agent” on site
Manual process	Uploads by engineers to a share, with Git or folder versioning	Whatever the team remembers	Anywhere

The manual route can work on a small site. Our FactoryTalk AssetCentre page lists the pieces: a scheduled upload, version control on the store, a tested restore procedure, a change log with an owner, and periodic verification. The discipline is the hard part, which is why automated tools usually win once a site passes a few dozen devices.

For the AMDT approach in detail, see the AMDT cluster. For a fuller side by side, see the PLC version control software comparison.

Who owns PLC backup software on site

A backup tool without an owner decays. Jobs fail quietly when a password changes, a device is replaced or a network path is closed, and a dashboard full of amber goes unread. Within a year the plant is back to believing it has backups it does not have.

The owner is usually a controls engineer or a maintenance lead with a few hours a week set aside, supported by IT for the server, storage and network paths. Their routine is short and dull, which is the point:

• Weekly: review failed jobs and drift alerts, and close each one
• After every project: add new devices and retire old ones, so coverage stays complete
• Quarterly: confirm the offline copy is current and restorable
• Yearly: run a restore test per device family and update the record of software releases

Write the role into a job description, not a project plan. Projects end; the backups have to keep running.

Limits and open questions

• Unnetworked devices. Older machines on serial links or isolated networks may need a manual upload or a site agent. Ask each vendor how they handle them, and count how many you have.
• Uploads lose information. On several platforms an upload from the controller carries no comments or descriptions. A good tool pairs the upload with the documented offline project.
• Safety controllers. Uploading is usually harmless; downloading is a controlled act with a safety signature. Treat restores of safety programs as a separate procedure.
• Cloud access to the plant floor. Cloud-delivered tools need a path from the OT network to the vendor. Review it against your OT network segmentation.
• Coverage claims. “Hundreds of device types” means little until your specific firmware and software releases are confirmed.

How to evaluate PLC backup software

• Does it back up every device class on your list, at your firmware and software versions?
• Does it compare each upload with the approved version, not only with the last upload?
• Can it reach unnetworked or segmented devices without weakening your network design?
• Where are the copies stored, and can one copy be made offline or immutable?
• Does it record the engineering software release each backup needs?
• What does a restore look like in the tool, and can you rehearse one in the trial?
• Who will own it on site, and what does the vendor or its partner provide to onboard each device family?
• What does it cost over three years, including implementation and support?

Deeper

• AMDT backup and recovery: how one multi-vendor platform structures backup jobs and restore
• Automated device backup in octoplant: jobs, schedules and unnetworked machines
• OT asset inventory: how the backup repository doubles as a configuration-based inventory

Back to the automation change management hub. If you want to know which of your devices would stop production longest without a backup, a plant systems assessment starts there.