octoplant Disaster Recovery: Known-Good Versions, Runbooks and RTO

What does octoplant disaster recovery give a plant on the worst day, and what does it leave to the plant? AMDT’s description is short: restore “the right version to the right device after failure, human error, unwanted change, or cyberattack”. The useful part of that sentence is “the right version”. Most slow recoveries are not caused by a missing backup. They are caused by not knowing which backup is safe to load.

This page covers known-good versions, the two recovery modes AMDT names, a runbook, two illustrative scenarios and how to think about recovery time for a line. The basics of what octoplant backs up are on the parent page, octoplant backup and recovery. Facts as of October 2026.

Known-good versions: the core of octoplant disaster recovery

The latest backup is not automatically the right one. A scheduled job stores whatever is running. If a night-shift edit broke a sequence on Tuesday, Wednesday’s backup contains the broken sequence. After a cyber incident, the most recent backups may contain the attacker’s changes. AMDT’s resilience page names that case directly: a compromised system “must be returned to a trusted configuration before production can safely resume”.

What makes a version known-good is evidence, not age:

• It was approved through change control, for example by check-in after an edit.
• It ran in production afterwards without a related fault.
• Later versions are explained, so you know what you lose by stepping back.

AMDT says octoplant can “restore not only the last program, but also earlier system statuses”. That capability is only as good as the labels on those earlier states. A history of 300 unlabelled versions is a slower recovery than a history of 20 with notes.

Per-device versus pattern-based recovery

AMDT lists “pattern-based or individual device recoveries” without a public definition of the first. The table gives our reading of the two modes; confirm the mechanics with AMDT for your device types.

	Per-device recovery	Pattern-based recovery (our reading)
Source	That device’s own version history	A standard version shared by identical machines or cells
Best fit	Unique machines, process skids, one-off OEM equipment	Repeated robot cells, identical lines across plants
Main risk	History was never labelled, so the right version is unclear	Local differences (addresses, offsets, calibrations) overwritten by the standard
What to check	Approval status and notes on recent versions	Which parameters are site-specific and must survive the restore

Why pattern-based matters at scale. AMDT’s Bosch B4M case study describes corrected versions at one location being distributed across the network. A multi-plant manufacturer with standard machines gains a lot from that, provided local differences are kept out of the standard.

An octoplant disaster recovery runbook

A runbook written before the event is what turns a backup into a recovery. This is a generic sequence for a single-device failure; adapt it per asset class and keep a printed copy at the line.

1. Make the machine safe. Lockout and tagout per site procedure. No restore on an energised, unsafe machine.
2. Classify the event. Hardware failure, bad download, unwanted change or suspected cyber incident. A suspected incident goes to step 3 before anything else.
3. If cyber is possible, escalate first. Bring in the incident response owner, and do not connect engineering laptops to the affected network until they say so.
4. Confirm the spare. Part number, hardware revision and firmware against what the failed device ran.
5. Select the version. The most recent known-good version, not the latest. Record which and why. After a suspected incident, also check the stored copy has not been altered since it was approved; NIST suggests validating baseline files against a stored hash before returning a device to that baseline (NIST SP 800-82 Rev. 3, appendix E.3.3).
6. Prepare the workstation. A clean engineering PC with the right editor version and licence, and a path to the device.
7. Download the selected version to the spare or cleaned device.
8. Verify. Upload from the device and compare with the selected version in octoplant. Any difference stops the restart.
9. Test before production. Run the machine through its functional checks with the line lead.
10. Release and record. A named person releases the machine. Note the version restored and the time taken for each step.
11. Re-apply lost changes through normal change control, not as a quick edit on the spot.

Two scenarios (illustrative)

Hardware failure on night shift. A PLC on a filling line fails at 01:30. The spare is on the shelf and its firmware matches. The technician has the runbook, selects the last approved version, downloads and runs the compare. The line is back within the hour. The same event with no spare on site, or a spare two firmware revisions behind, is a day or more regardless of the backup tool.

Ransomware on the engineering network. Engineering PCs and the SCADA server are encrypted. Several controllers keep running, but nobody trusts their logic. The recovery order is set by incident response, not by octoplant. Once the network is cleared, clean engineering stations are rebuilt from images, each controller is uploaded and compared against its last known-good version, and only the ones that differ are restored. The repository must itself have been protected from the attack, which is an architecture question to settle in advance. The vendor-neutral sequence is on PLC ransomware recovery.

What octoplant disaster recovery cannot do

• Spares. It holds the program, not the hardware.
• Firmware. Matching firmware on the replacement is a plant inventory task.
• People. Someone qualified must download, test and release. A night shift without that person waits.
• Engineering PCs. If the stations and their licences are lost, imaging and licence recovery come first. See automated device backup for how PC images fit in.
• Safety validation. A restored program on a safety-related machine still needs the site’s validation steps.

Our own warehouse controls and network recovery illustrates the point. That project did not involve AMDT or octoplant. Backups were only partly in place: the panel PCs had no recovery path until their files were backed up during the visit, and a protocol gateway that failed mid-week had to be brought back to a working configuration. Both are the kind of gap that a current backup of every device, with a tested restore, closes before the bad day.

RTO thinking for a line

A line’s recovery time objective is the sum of its slowest steps, not the speed of the restore button. AMDT’s thyssenkrupp Presta case reports that “restarts that used to take several hours can now be realised in just a few minutes,” which shows what is possible when the other steps are also ready.

Step	What usually sets its length	How to shorten it
Detect and diagnose	Alarms, skills on shift	Alerts on device changes and job failures
Spare hardware	Stock on site, lead time	Critical spares list with firmware recorded
Version selection	Labels and approvals	Change control on every edit
Download	Editor, licence, network path	A ready, clean engineering station
Verify and test	Compare tools, functional checks	Upload-and-compare, written test steps
Release	Who is authorised	A named on-call person

Put a cost on each hour with our guide to manufacturing downtime, then decide where the money goes. Often it is a spare CPU, not software.

Where it gets hard

Recovery that is never rehearsed. A restore tried for the first time during a breakdown takes several times longer than one practised quarterly.

Protecting the repository. The server that holds every program is a target in a cyber incident. Its own backups, access controls and network placement need as much thought as the devices it protects. NIST describes a “backup-in-depth” approach, with layers “(e.g., local, facility, disaster) that are time-sequenced such that rapid recent local backups are available for immediate use and secure backups are available to recover from a massive security incident” (NIST SP 800-82 Rev. 3). Applied to an octoplant installation:

Layer	What it protects against	In an octoplant setup
Local	One failed device, a bad download, an unrecorded edit	The octoplant repository on the OT network, used every day
Facility	Loss of the octoplant server or its database	A tested copy of the repository and database on other hardware on site
Disaster	Ransomware across the site, fire or flood	An offline or off-site copy, which CISA says should be kept offline because ransomware hunts for reachable backups (CISA)

See NIS2 and IEC 62443 for how the standards frame this.

Pattern versus local reality. Standard versions on machines that drifted locally can overwrite the differences that made them run.

Back to backup and recovery or the AMDT hub.