What is a backup?
A backup is a separately stored copy of data, configurations or entire systems, made so that you can bring them back (a restore) and resume normal operation (recovery) after loss, corruption, a failure or a cyberattack. A backup is only valuable once restoring it has been shown to work; that is why making backups, restoring backups and restore testing belong together. Backups are the foundation of digital resilience: they limit the damage from a ransomware attack, hardware failure, human error or fire. In OT environments, a backup is not only about data but above all about the programs and settings of the PLCs, HMIs, SCADA and DCS systems that keep a factory or plant running.
🧠 What types of backup are there?
Backups differ in what is copied and where the copy is kept:
| Type | Description | Typical use |
|---|---|---|
| File backup | Copy of documents, databases or log files | File servers, historian databases |
| Full system backup (image) | Disk image including operating system, software and settings | Servers, engineering stations, operator stations |
| Configuration backup | Export of device programs and settings | PLC projects, HMI projects, switch configurations |
| Snapshot | Point-in-time copy of a volume or virtual machine | Virtualised SCADA servers (virtualisation) |
| Cloud backup | Copy held by an external service or a private cloud | Office IT, long-term archive |
| Offline / air-gapped | Copy physically or logically separated from the network (air gap) | Tape, removable disks, vault storage |
| Immutable backup | Copy that cannot be changed or deleted during a retention period | Protection against ransomware and abused admin accounts |
🔧 What is the difference between full, incremental and differential backups?
The backup method determines how much storage and time a backup takes, and how quickly you can restore:
| Method | What is copied | Advantage | Disadvantage |
|---|---|---|---|
| Full | All data, every time | Simplest and fastest restore | Uses a lot of storage and takes long |
| Incremental | Only changes since the previous backup (of any type) | Fast and storage-efficient | Restore needs the full backup plus every increment |
| Differential | All changes since the last full backup | Restore needs only two sets | Grows every day until the next full backup |
A common schedule is a weekly full backup with daily incremental or differential backups. How often you back up follows from the RPO (Recovery Point Objective: how much data you can afford to lose); how quickly you must be able to restore follows from the RTO (Recovery Time Objective).
🎯 What is the 3-2-1 rule?
The 3-2-1 rule, popularised by photographer Peter Krogh, is the best-known rule of thumb for a robust backup strategy:
- 3 copies of your data: the original plus two backups
- 2 different media, for example disk and tape, or disk and object storage
- 1 copy at another location, outside the building or site
Because ransomware groups now deliberately hunt for backups to delete or encrypt them, the rule has been extended to 3-2-1-1-0:
- +1 copy offline or immutable - unreachable or unchangeable, even for an attacker with stolen administrator rights
- 0 errors - every backup is verified and proven usable with a test restore
🏭 What should you back up in an OT environment?
An OT backup is more than a copy of the servers. To recover a production line or process plant you need:
| Component | What to capture | Point of attention |
|---|---|---|
| PLC and safety PLC programs | Project files, hardware configuration, data blocks and current values | The online version may differ from the project file on the laptop |
| Firmware | Exact firmware version per device and the matching vendor installation file | Firmware is restored from the vendor package, not from the PLC |
| HMI and SCADA projects | Projects, screens, alarm definitions, user management | Only runs with the right software version and licence |
| DCS configuration | Engineering database, control strategies, I/O assignment | Often only restorable with the vendor’s tooling |
| Network components | Configurations of switches, routers and firewalls | Including VLANs, firewall rules and certificates |
| Engineering stations | Full image including engineering software, licences and drivers | Old software versions are often no longer downloadable |
| Process data and recipes | Historian data, recipes, batch settings, operator parameters | Recipes often change outside the project file |
| Identity and infrastructure | Active Directory, DNS, backup catalogue | Without these services nothing starts up |
🔁 How does a restore work?
A restore is the process of putting data, software or configurations back from a backup. It is the practical execution of your backup strategy and the moment you find out whether that strategy holds up. A controlled restore follows five steps:
- Choose the restore point - which backup do you use, and from which moment? After a cyberattack, the restore point must predate the compromise. Attackers often spend weeks inside a network before they strike, so the newest backup is not automatically clean. Check the candidate backup against known indicators of compromise.
- Prepare a clean environment - restore into an isolated, clean network segment, not onto the system that is still infected. The US agency CISA warns against re-infecting clean systems during recovery, and stresses that leftover malware must be found before you rebuild from backups.
- Restore in order of priority - first the core infrastructure (identity, DNS, network), then the systems with the shortest RTO, following a predefined list of critical assets. In OT this often means safety functions and controllers before reporting and the historian.
- Validate - check checksums and integrity, test operation and communication with other systems such as the PLC, SCADA and historian. Compare a restored PLC program with the last approved version.
- Record and release - log who restored what and when (an audit trail), and have the process owner formally release the system before production restarts.
The kind of restore you choose depends on what went wrong:
| Type of restore | What is put back | Typical OT scenario |
|---|---|---|
| File or configuration restore | Individual files, a PLC project or a switch configuration | A faulty change, an accidentally deleted recipe |
| Full system restore | The entire system to an earlier point in time | A failed update of a SCADA server |
| Bare-metal restore | Operating system, drivers, software and data onto bare or new hardware | A failed disk or a replaced engineering station |
| Live or instant restore | A virtual machine that boots directly from backup storage while the final restore runs in the background | Virtualised operator or SCADA servers with a short RTO |
| Rebuild from a golden image | A preconfigured, tested standard image, topped up with the latest data | Ransomware on many workstations at once |
With bare-metal restores and golden images, watch the hardware: CISA points out that some images will not install correctly on different hardware or platforms. For older industrial PCs it is therefore wise to keep spare hardware or a virtualised fallback ready.
🧪 How do you test that a restore works?
Restore testing means restoring a backup on a trial basis to prove that recovery succeeds within the agreed time and without unacceptable data loss. It is the “0” in 3-2-1-1-0. Tests vary greatly in depth:
| Test type | What it proves | Common frequency |
|---|---|---|
| Automatic integrity check | The backup is complete and undamaged (checksum, readability) | After every backup |
| Sample restore | Individual files or a PLC project can be restored and used | Monthly or quarterly |
| Full system restore | A server or engineering station can be completely rebuilt in a test environment | At least annually per critical system |
| Disaster recovery exercise | The whole chain, including people, sequence and communication, meets the RTO and RPO | Annually and after major changes |
NIST SP 800-53 makes this concrete: control enhancement CP-9(1) requires backups to be tested periodically for reliability and integrity, and CP-9(2) requires a sample of backup information to be used in restoring selected system functions as part of contingency plan testing. Measure how long each restore took and compare it with the RTO; a measured recovery time that is consistently above the RTO belongs in your risk register as a finding.
In OT you preferably do not test on the running plant. The usual approach is a test rig with a spare PLC, or a virtualised copy of the SCADA and engineering servers in a separate test environment along the lines of OTAP. That way you discover in advance that a licence is tied to old hardware, that a firmware version can no longer be downloaded, or that a recovery procedure misses a step.
🔐 How do you protect backups against ransomware?
Attackers know that a working backup makes their ransom worthless. The US agency CISA warns that ransomware groups search for and delete reachable backups, and attack backup software using stolen credentials or known vulnerabilities. Key measures:
- Offline or immutable copy - at least one copy out of reach of the production and domain network
- Separate administration - dedicated accounts for the backup environment, not tied to the regular domain, and with MFA
- Encryption - encrypt backups so that stolen copies do not become a data breach
- Integrity checks - checksums or hashes, so you know a backup has not been tampered with
- Golden images - preconfigured, tested images of critical systems for rapid rebuilds
- Authorised recovery - only authorised administrators may perform a restore (RBAC), with an audit trail of every recovery action
The lesson of NotPetya (June 2017) is the classic example. Maersk had to reinstall around 4,000 servers and 45,000 PCs. Backups of the servers existed, but not of the domain controllers: all domain controllers synchronised with each other and were wiped at the same time. Recovery was only possible thanks to one domain controller in Ghana that had been offline because of a power cut. The lesson: a restore is only as strong as its least protected link, and identity services need an offline copy too.
🧱 Which standards and laws require backups?
| Framework | Backup requirement |
|---|---|
| IEC 62443-3-3 | SR 7.3 Control system backup from security level 1, without disrupting normal plant operation; RE 1 backup verification from SL 2; RE 2 backup automation from SL 3; SR 7.4 covers recovery and reconstitution |
| NIS2 | Article 21(2)(c) lists business continuity, such as backup management, disaster recovery and crisis management |
| Implementing Regulation (EU) 2024/2690 | For digital infrastructure and ICT service providers under NIS2 (such as cloud, data centre and managed service providers): backup plans including configuration data, storage outside the system’s network and at a sufficient distance from the main site, regular integrity checks and documented recovery tests |
| Cybersecurity Act | Dutch transposition of NIS2 (Cyberbeveiligingswet), in force since 15 August 2026 |
| NIST SP 800-53 | CP-9 System backup, with CP-9(1) testing for reliability and integrity, CP-9(2) restore testing using sampling and CP-9(8) cryptographic protection |
| ISO 27001 | Control 8.13 (information backup) in Annex A of the 2022 edition |
| BIO | Dutch government baseline, based on ISO 27001/27002, which adopts their backup control |
For compliance, it is not enough to have backups; you must be able to demonstrate that recovery works, for example during an audit.
🛠️ How do you set up OT backups step by step?
- Take inventory - start from an up-to-date asset inventory: which controllers, servers, network components and engineering tools are there, and which versions are running?
- Set RPO and RTO per system - through a business impact analysis. A PLC program rarely changes; a historian database changes continuously.
- Choose the method - manual exports rarely suffice with dozens of controllers. Specialised tools such as octoplant from AMDT (successor to versiondog and AutoSave) or Rockwell FactoryTalk AssetCentre collect programs automatically and compare them with the previous version.
- Link to change control - take a backup before and after every change, and record differences through change management and version control.
- Store securely - following 3-2-1-1-0, with one copy outside the OT network and one offline or immutable copy.
- Test recovery - periodically restore a PLC program to a test rig and rebuild an engineering station or SCADA server in a virtual environment.
- Document it - include recovery procedures in your disaster recovery plan and incident response plan, including who performs each step.
A widely used practice is a daily automatic comparison of all PLC programs against the last approved version. This not only secures a backup but also reveals unauthorised changes, whether they come from a colleague, a supplier or malware.
🔄 What is the difference between backup and disaster recovery?
| Backup | Disaster recovery |
|---|---|
| A copy of data, configuration or a system | A complete recovery process for IT and OT services |
| Focused on preserving data | Focused on business continuity and limiting downtime |
| A technical measure, often automated | An orchestrated process with roles, priorities and runbooks |
| A building block of disaster recovery | Uses backups as the source for recovery |
❓ Frequently asked questions
How often should you make a backup?
How often you make a backup depends on the RPO: the maximum amount of data you can afford to lose. For office systems and historians this is often daily or more frequent. For PLC and HMI programs, a backup after every change plus a periodic automatic check is the usual practice.
Is RAID or replication a backup?
RAID and replication are not a backup, because they immediately copy an error, a deletion or encryption by ransomware. They increase availability but offer no way back to an earlier, clean version. A real backup is a separate copy with version history.
Why is a PLC backup different from an IT backup?
A PLC backup consists of the project file and configuration rather than a disk image, and it can only be restored with the right engineering software and firmware version. In addition, the program in the PLC may differ from the file on the engineer’s laptop. That is why OT backup tools read the online version directly from the controller.
What is the difference between backup, restore and recovery?
A backup is the stored copy, a restore is putting that copy back, and recovery is the wider return of the service to normal operation. A restore is therefore one step within recovery, alongside finding the cause, cleaning infected systems and releasing the plant. Without a working restore there is no recovery.
How often should you carry out restore testing?
A common practice is an automatic integrity check after every backup, sample restores every month or quarter, and a full restore test of critical systems at least once a year and after major changes. IEC 62443-3-3, NIST SP 800-53 and NIS2 Implementing Regulation (EU) 2024/2690 explicitly call for tested backups. A backup that has never been restored is an assumption, not a guarantee.
Should OT backups be stored in the OT network?
A working copy of OT backups usually sits in the OT network, so recovery is fast and does not depend on IT. However, there must also be a copy outside that network, offline or immutable, so that an attack on the OT environment does not hit all backups as well. Transfers preferably run through a controlled route such as a DMZ.
📌 In summary
A backup is a separately stored, tested copy of data, configurations and systems, and therefore the last line of defence against data loss, downtime and ransomware. In OT the focus is on PLC, HMI, SCADA and DCS configurations, firmware versions and engineering stations; follow 3-2-1-1-0, link backups to change control and prove with regular restore testing that you can restore within the RTO, as IEC 62443-3-3 and NIS2 require.