octoplant Backup and Recovery: How Industrial Restore Actually Works

octoplant backup is the part of AMDT’s platform that most plants buy it for: scheduled copies of what is running inside PLCs, robots, HMIs, drives and network devices, held in a versioned repository, and the means to put the right version back after a failure. This page explains why that is harder than backing up a file server, what octoplant captures, how a restore works, and what still decides how long a line stays down. It is an independent overview for engineering managers, controls leads and OT security leads, written from public sources as of October 2026.

AMDT frames the problem in one line: “Industrial recovery isn’t file recovery.” That is the right place to start.

Why industrial recovery is not file recovery

An IT backup copies bytes from a disk and puts them back. A controller does not work that way. Its program lives in the device’s memory, in a vendor format, alongside parameters, tag values, firmware and hardware configuration that may not be in any project file on a laptop. AMDT puts it this way: “Backing up an industrial device isn’t the same as copying a file,” and restoring production means rebuilding the “program, parameters, configuration, and machine-specific data.”

	IT backup (servers, PCs)	Automation backup (PLCs, robots, drives)
What is copied	Files, databases, disk images	Running program, parameters and configuration, read from the device
How it connects	Agent on the host or a hypervisor snapshot	Vendor protocol or engineering-software integration, per device type
Source of truth	The disk	The device. The project on the laptop may be older
What “changed” means	A file’s bytes differ	A rung, a setpoint or a robot point differs, and someone needs to know which
Restore target	The same or a new host	A spare device, often with matching firmware and hardware revision
Who restores	IT, often remotely	A controls technician or engineer, usually at the machine
Proof it worked	The service starts	Upload again, compare with the stored version, then run the machine

The plant consequence. A server backup policy that reports 100% success can coexist with a plant where nobody has a current copy of the palletiser PLC. The two are measured differently and owned by different teams, which is why automation backup tends to fall into the gap between IT and maintenance.

What octoplant backup covers

AMDT describes “scheduled, verified backups of PLCs, HMIs, SCADA, DCS, robots, CNCs, drives, and other industrial systems”. The product page adds documents and other file types, and says it works for “unnetworked or partially networked machinery and plant”. The asset classes, with what a plant loses without each:

Asset type	What is captured	What you lose without it
PLC programs	Logic, data blocks, hardware configuration	The line’s behaviour. The most visible loss
Robot programs	Programs, points, frames, system settings	Hours of re-teaching per robot
HMI and SCADA projects	Screens, alarms, tags, scripts	Operators lose visibility and alarm handling
Drive parameters	Parameter sets for VFDs and servo drives	A twenty-minute drive swap becomes a day of tuning
Network configurations	Switch, router and firewall configuration	VLANs, port settings and rules rebuilt from memory
PC images	Engineering stations, HMI PCs, servers	A reinstall of Windows, runtimes and licences
Documents and generic files	Drawings, manuals, recipes, files on shares	The context needed to make the rest useful

These are categories, not a support list. AMDT states more than 180 industrial device types natively supported and 160+ vendors, but the full matrix is behind the myAMDT login. The supported devices page gives examples and explains how to verify coverage for your own installed base.

PC images are a special case. octoplant is not itself a disk-imaging tool. AMDT sells an Image Service Integration that is meant to “integrate supported image-backup approaches into the wider Octoplant protection strategy”, which means the imaging product is a separate decision. The automated device backup page covers this.

How an octoplant restore works

The mechanism has two halves: the backups that run every day, and the restore that runs on the worst day.

Every day, scheduled jobs connect to each device, upload what is running, and compare it with the stored, approved version. AMDT describes this as jobs that run “in the background”, with alerts when backups fail, devices become unreachable, or the running state deviates from the expected version. A difference becomes a new version in the history, with a timestamp, so the repository holds a record of what each device held over time. The change-tracking side of this is covered under version control and change management.

On the worst day, the restore runs in roughly this order:

1. Identify the device and the failure. Hardware fault, wrong download, unwanted change or cyber incident.
2. Select the version. Not automatically the latest. AMDT’s wording is to restore “the right version to the right device”, and the product page says earlier system states can be restored, not only the last program.
3. Prepare it. Open the version in the native engineering tool or through the device integration.
4. Download to the repaired, replaced or cleaned device.
5. Verify. Upload again and compare against the stored version before handing the machine back to production.

AMDT lists “pattern-based or individual device recoveries”. The difference, and a fuller runbook, is on the disaster recovery page.

What drives recovery time

The version, first. The common slow recovery is not a missing backup. It is three backups and nobody sure which one matches the machine that worked last Thursday. A versioned history with change records turns that into a lookup. This is also why a backup that is never compared with the device is weaker than it looks.

Hardware and firmware. A program restored to a spare with the wrong firmware or module revision may not load. The tool holds the program; it does not hold the spare.

The engineering software. If the restore needs the vendor’s editor at a specific version, someone needs a licensed, working copy on a machine that can reach the device.

Access and people. Unnetworked machines need someone at the panel with a cable. A night shift with no one qualified to download and sign off adds hours that no software removes.

Verification. Skipping the post-restore compare saves ten minutes and risks running a line on the wrong logic.

For the cost side of those hours, our piece on manufacturing downtime sets out how to put a number on them.

Public cases: thyssenkrupp Presta and Bosch

Two published AMDT case studies show how large manufacturers use octoplant backup. Both are AMDT’s accounts and we have not verified them independently.

thyssenkrupp Presta. AMDT’s case study describes 24 production plants making steering systems, with octoplant used to back up the production chain. The headline claim: “restarts that used to take several hours can now be realised in just a few minutes.” The project manager quoted calls octoplant “part of our recovery strategy,” a phrasing worth noting: the tool is one part of a strategy, not the strategy.

Bosch B4M. “Backup for Manufacturing” is a global Bosch service built on octoplant. Each plant runs its own installation, and Bosch’s central IT maintains a central installation that delivers standardised components to the sites. The case study publishes no metrics. Its interest is organisational: backup and recovery run as an internal service with a central owner, which is the model that addresses the IT and maintenance gap described above.

Measuring octoplant backup against NIST SP 800-82

The most useful yardstick for any OT backup tool is not a vendor feature list. It is the backup section of NIST’s Guide to OT Security, SP 800-82 Rev. 3 (section 6.2.4.3), which says what an OT backup programme has to achieve. Mapping octoplant against it shows where the tool carries the load and where the plant still does.

NIST SP 800-82 Rev. 3 asks for	What octoplant contributes	What stays with the plant
Backups of “configuration files, and programs at regular intervals”	Scheduled upload jobs per device, unlimited in every edition	Setting the interval per asset; reaching unnetworked machines
“Verify the backups for reliability and integrity”	A compare of each upload against the stored version	Defining what “verified” means; restoring to a spare now and then
An on-site copy “accessible to all personnel who may need access during a recovery event”	A central repository on the OT network	Night-shift access, and logins that still work when the domain is down
A second copy that “the same incident that disrupts the primary data cannot modify or destroy”	No built-in off-site or offline copy of the repository is publicly documented	An off-site or offline copy of the repository itself
“Test the restoration process from backup data as part of contingency plan testing”	Restore, then upload and compare to prove it	Scheduling the tests and holding the spare hardware
Backup procedures “included in configuration or change management processes”	Check-out, check-in, approvals and the audit trail	The written procedure, and the discipline to follow it
A list of backups “including installation media, license keys, and configuration information”	Documents stored next to programs, not counted as devices	Keeping editor installers and licence keys current and findable

The row most plants miss is the fourth. octoplant is the backup of the devices; something has to be the backup of octoplant. CISA’s ransomware guidance makes the same point for every system: “maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario” (CISA). A repository that ransomware can reach is not a recovery plan. The architecture page covers where the server should sit.

Limits and open questions

• The device matrix is gated. Coverage claims are AMDT’s, and the detail is behind the myAMDT login. Verify every device family and editor version you run.
• Per-edition features are not public. AMDT publishes three editions (Core up to 50 devices, Plus 100+, Premium 250+) and states unlimited jobs, but not which recovery features sit in which edition. See editions and licensing.
• “Verified” needs defining. AMDT says backups are verified. Ask what that check covers: a completed upload, a successful compare, or a restore test.
• Imaging is a separate product. PC image backup depends on an imaging tool you choose and integrate.
• Restore still needs people and parts. The public material describes fast recovery; it does not remove the need for spares, firmware and qualified staff.
• Alternatives exist. FactoryTalk AssetCentre covers Rockwell-centric sites, and Copia Automation now markets recovery from running devices. The vendor-neutral view is on PLC backup software.

How to evaluate octoplant backup

• List your device families and editor versions, and get written confirmation of support for each.
• Ask how unnetworked machines are backed up, and who does it.
• Ask what “verified backup” means in the product, step by step.
• Watch a restore of one of your own device types, from version selection to post-restore compare.
• Confirm which engineering software must be installed on the server or clients, and who licenses it.
• Ask how alerts reach someone at 02:00, and who owns them.
• Decide the imaging tool for PCs before rollout.
• Plan a quarterly restore test on a spare. A backup nobody has restored is a hypothesis.

Not sure what is on your floor before you start? A plant systems assessment builds that inventory independently of any tool.

Deeper

• octoplant Automated Backup: jobs and schedules, upload-and-compare, unnetworked machines, PC images, and what a good backup policy looks like.
• octoplant Disaster Recovery: known-good versions, pattern-based versus per-device recovery, a runbook, and RTO thinking for a line.

For a controller hit by ransomware, the vendor-neutral sequence is on PLC ransomware recovery. Back to the AMDT hub, or across to version control and change management.