OT Backup and Recovery: Could You Restore Your Factory?

It might run Windows 7. Perhaps Windows XP. It boots every morning, talks to a PLC, drives an HMI and quietly helps control a machine worth hundreds of thousands of pounds. Nobody has touched its configuration in years, and nobody particularly wants to.

Then one morning it does not boot. The hard drive has failed.

What happens next? Can somebody restore the machine? Does anyone have a complete backup? Where is the application installer? Does it need a licence? Where are the drivers for the proprietary interface card? Does the machine builder still exist? Could the system be restored onto a different industrial PC? What version of the PLC programme should be running alongside it? And how long can production wait while somebody works all of that out?

This is Operational Technology backup and recovery, and it is becoming a serious part of industrial resilience. Cybersecurity is certainly part of the story, but ransomware does not need to strike for an OT recovery plan to become extremely valuable. Sometimes things simply break.

What exactly are we backing up?

This is where OT backup immediately becomes harder than office backup. Picture a reasonably ordinary automated machine. It contains a PLC controlling the physical process. Operators interact through an HMI. An industrial PC runs specialist machine software. An engineering workstation holds the programming environment. A managed switch connects everything. A 4G or 5G industrial router provides remote access for the machine builder. Production data may also flow to a SCADA system, a historian or a cloud platform.

So what actually is the backup? Copying the files on the Windows computer solves only part of the problem. A genuinely recoverable machine can need copies of:

• the industrial PC operating system, applications and application configuration
• specialist device drivers and licence files
• the HMI project, and the PLC programme, hardware configuration, safety programme and firmware details
• recipes and machine parameters
• SCADA and historian configuration and data
• switch, router, firewall and VPN configuration
• certificates, keys and IP addressing
• software installers, firmware files, passwords and recovery credentials
• electrical and network drawings, and documentation explaining how it all fits together

Suddenly "we back up the server every night" does not sound quite as reassuring.

Consider the PLC

A Programmable Logic Controller is designed to be extremely reliable, and that reliability can ironically encourage poor backup practice. A PLC might run continuously for 15 years without needing to be replaced. People change jobs. Integrators change. Laptops are replaced, servers migrated, companies merged. Documentation disappears. Meanwhile the PLC keeps doing exactly what it was programmed to do.

Until it does not. The power supply fails, internal storage becomes corrupt, or the controller simply dies. A maintenance engineer fits a replacement. Now comes the important question: where is the programme?

There might be a file called Machine_Backup_FINAL.zip. There might also be Machine_Backup_FINAL2.zip, Machine_New_2021.zip, Machine_MODIFIED.zip and Machine_Daves_Laptop.zip. Which one is actually running in the failed controller? That is not an academic problem. It is one of the fundamental challenges of OT backup.

"The programme is on the engineer's laptop"

Spend enough time around industrial automation and variations of this sentence appear constantly. The programme exists. Someone has a copy. Probably. It might be on an engineering laptop, or a USB stick, or the integrator has it, or there is a copy on the company server. But when was the machine last modified, and was the central copy updated afterwards?

Engineers discussing exactly this problem routinely describe environments where PLC programmes live on individual laptops, where safety passwords have been lost, and where the original projects for some controllers no longer exist at all. The familiar recovery process is simple enough: the PLC needs replacing, someone finds the person who has the file, and they restore it. That works, right up until that person is not there.

A backup is not the same as a recoverable system

This distinction runs through everything in OT. Suppose an industrial PC is backed up every night and the software reports success. The PC fails, a replacement is installed, the image is restored, and Windows starts. Then the specialist application fails because the replacement computer uses a different storage controller. Or the application expects a hardware licence dongle. Or a proprietary PCI card is incompatible. Or the machine needs a driver that has not been made for 15 years.

The backup was perfectly good. The recovery failed.

Old technology is not necessarily bad technology

Walk through an office and a Windows XP machine would be alarming. Walk through an established manufacturing facility and the picture is different. The computer may run XP because the machine application was written for XP. The machine might have been commissioned in 2008. It still produces 10,000 good components a day. Replacing the software could mean replacing or revalidating the entire control system, and nobody spends a six-figure sum modernising something simply because Microsoft no longer likes the operating system.

OT equipment frequently stays in service for decades, and this is exactly the problem that whole-machine imaging was built to solve. Acronis, which many people remember from its True Image PC backup software, has taken that lineage directly into industry. Its Cyber Protect for OT platform supports Windows systems stretching back to the XP era alongside modern Windows and Linux, and it can run inside fully air-gapped industrial networks with no external connection at all. It protects the kinds of systems that sit around a process rather than the process itself: HMIs, SCADA servers, engineering workstations, jump servers and historians, in Purdue model levels 2, 3 and 3.5.

Recovery by the people who will actually be standing there

There is another industrial complication: the IT department might not be present. A machine fails at 2:30 on a Sunday morning. The production operator is there. Maintenance is there. Perhaps an electrical engineer is there. The senior IT administrator is not, and the machine builder's automation engineer certainly is not. Every hour of waiting is potentially another hour without production.

This is why the useful capability is operator-led recovery. Acronis promotes One-Click Recovery, intended to let local staff without specialist IT knowledge restore a failed OT computer from a prepared recovery image, turning an outage that used to run to hours or days into one measured in minutes. Pair that with Universal Restore, which handles the driver and storage-controller differences when restoring an image onto dissimilar hardware, and you no longer need to find an identical 14-year-old industrial PC at three in the morning. For brownfield OT, that is genuinely valuable.

But Windows is only half the problem

Here we need to be careful about what a product like Acronis actually solves. It can recover the computers surrounding an industrial process. It does not magically recover the process itself.

Return to the PLC. If its programme disappears, somebody still needs the correct engineering project. For a Siemens installation that might mean TIA Portal. For Rockwell Automation it could mean Studio 5000 and its associated asset-management tools. Schneider Electric, Mitsubishi, Omron, Beckhoff and the CODESYS ecosystem all have their own programming, configuration and backup approaches. There is also a category of specialist industrial version-control platforms, such as AMDT's octoplant (the successor to versiondog and AutoSave), built specifically to keep versioned, vendor-independent copies of PLC, HMI, robot, CNC and SCADA programmes and to flag when what is running no longer matches what is stored.

A properly protected line therefore needs several kinds of backup working together:

• System image so an industrial computer can be rebuilt
• Application backup to preserve specialist software data and configuration
• PLC and controller backup to preserve control logic and controller configuration
• Device configuration backup for switches, routers, drives and other configurable infrastructure
• Documentation that explains how the pieces are supposed to fit together

None of these fully replaces the others.

Configuration drift makes it harder still

An integrator commissions a machine in January and everything is backed up. In March an engineer changes a timer in the PLC. In June another adjusts the HMI. In August the network configuration changes. In October a new recipe is created. The January backup may still restore perfectly. It just no longer represents the machine.

This is configuration drift, and it produces one of the most dangerous false assumptions in industrial recovery: "we have a backup." The better question is whether you have a backup of the state you actually want to restore. That needs version control, change management and, ideally, automated configuration collection rather than reliance on somebody remembering to copy a project onto the server.

When it is an attack, not a failure

Now cyber threats. They matter enormously, but they make more sense treated as another cause of recovery rather than the reason backup exists. Ransomware might encrypt an HMI. An attacker might compromise an engineering workstation or corrupt a SCADA server. An attacker could even modify PLC logic.

That last one is not hypothetical. The documented attacks on Unitronics Vision series PLC and HMI devices, attributed to the IRGC-affiliated group CyberAv3ngers, hit internet-connected controllers in the water sector that were exposed with default or no passwords on their default port. A December 2024 CISA advisory update showed the activity went well beyond changing a screen: the attackers built custom ladder-logic files for different device models, replaced the legitimate logic with their own, renamed devices to hinder operators regaining access, rolled software versions backwards, disabled upload and download functions and changed default ports. The UK's NCSC noted targeting of these devices as part of the wider campaign.

From a backup perspective, the resulting question is remarkably similar to hardware failure: how do we return this equipment to a known-good state? But cyber incidents add one difficult complication, which is establishing which backup is clean.

Four numbers worth knowing

Industrial recovery planning tends to circle four metrics. The last one is the newest, and for a physical process it is arguably the most important.

For an industrial system, that final question often matters more than any of the others. A quick restore that reintroduces malware or corrupted logic is not a recovery.

Failed updates are a reason for backup too

A much less dramatic scenario: someone installs an update and the machine stops working. No ransomware, no attacker, no incident-response team. Just an update that does not agree with a 12-year-old industrial application. Acronis addresses this with what it calls fail-safe patching, taking an image before a patch is applied so the system can be rolled back if the update causes problems. That is resilience, not cybersecurity theatre. Something changed, the process stopped, so put it back to the last known working state.

What about the router?

Industrial connectivity deserves the same treatment. Picture a remote pumping station: a PLC, an industrial switch, a 4G or 5G router, a VPN and a SCADA control centre. The router fails and a replacement is taken from stores. Can anyone configure it? Which APN does it use? Is there a private network? What firewall rules were set? Which VPN certificates are needed? What LAN address, what port forwards, what SIM settings, what routing rules?

The PLC can be running perfectly while the site stays unreachable because nobody backed up a £300 router's configuration. This is exactly the territory covered in our guides to remote access to SCADA systems and private versus public IP for cellular IoT: the addressing, APN and VPN decisions that determine whether a replacement router can actually be brought back into service. Treat that configuration as part of the backup, not an afterthought.

Think about recovery in layers

A useful way to approach an industrial system is to divide recovery into layers and ask, for each, whether you could actually rebuild it.

• Physical equipment: can failed hardware be replaced?
• Controller: can PLC logic and configuration be restored?
• HMI: can operators regain control and visibility?
• Industrial computers: can operating systems, drivers and specialist applications be restored?
• Network: can switches, firewalls, routers and VPNs be reconstructed?
• Supervisory systems: can SCADA, historians and engineering systems be recovered?
• Business integration: can MES, ERP, quality and logistics systems reconnect?
• Documentation: does anybody actually know how all of the above is meant to work?

A factory is not recovered because Windows booted. It is recovered when the physical process can safely operate again.

The minimum viable factory

Research published in 2026 proposes a useful idea: Minimum Viable Factory Recovery. Its argument is that restoring servers is not the same as restoring manufacturing capability. A plant can rebuild its computers yet remain unable to authenticate operators, trust engineering workstations, schedule production, reconnect OT equipment or release finished product. The work identifies recovery failure modes including untrusted restore points, backup over-confidence, identity failure, unsafe OT reconnection, dependency blindness and a plain lack of proof that recovery actually works.

Instead of trying to restore everything at once, the sensible objective is the smallest combination of trusted systems needed to resume useful, safe production. Perhaps six lines normally run; after a major failure, getting one safely operational is the first goal. Perhaps ERP integration can wait while schedules are entered manually and cloud analytics stay offline. The immediate aim is not "restore everything" but "restore what we need to operate safely." That is a far more practical definition of resilience.

Could you restore your factory tomorrow?

Here is the exercise every organisation running industrial equipment should probably do. Choose an important machine and pretend it failed five minutes ago. Not one hard drive: assume the industrial computer is completely dead and the PLC needs replacing. Then ask:

• Do we have the current PLC programme, and do we know it is current?
• Do we know the PLC model and firmware?
• Do we have the HMI project and the industrial computer image, and can that image actually be restored?
• Do we have the application licences and the drivers?
• Do we have replacement hardware?
• Do we have the switch, router and VPN configuration, certificates and IP addresses?
• Do we know what external systems the machine depends on?
• Could someone other than the engineer who installed it perform the recovery?
• When did we last prove that any of this actually works?

If those questions produce uncomfortable answers, buying another firewall is not necessarily the first priority. Building a proper backup and recovery plan might be.

Backup should be treated like a spare part

Industrial companies understand spare parts. If a critical motor has a six-week lead time, somebody keeps one on the shelf, and nobody calls that wasted money. OT backup should be treated the same way. The PLC programme is a spare part. The HMI project is a spare part. The industrial PC image, the router configuration, the software licences and drivers are all spare parts. They are digital spare parts, and like the physical components in the maintenance store they are almost worthless if nobody can find the correct one when the machine stops.

From backup to operational resilience

This is ultimately why companies such as Acronis are moving into Operational Technology, and the opportunity is larger and less glamorous than protecting factories from ransomware. Machines fail. Storage fails. Computers fail. Controllers fail. Engineers make mistakes. Updates go wrong. Configurations become corrupted. People leave. Documentation disappears. And, occasionally, attackers get in. The common requirement across all of it is recovery.

For decades, industrial organisations have spent enormous sums making physical processes reliable. As those processes come to depend on computers, PLCs, networks, cellular connectivity and edge devices, the same discipline needs to apply to their digital components. The goal is not "we have backups." It is "we know how to restore this process, we know what we need to do it, and we have proved that it works." That is the difference between backup and resilience, and when the machine that has quietly run for 15 years finally stops at 2:30 on a Sunday morning, the difference becomes very valuable indeed.

Frequently asked questions