Ransomware crews no longer just encrypt your files - they hunt your backups first, because a company that cannot restore is a company that pays. For industrial operators, the stakes are higher than lost spreadsheets: losing your SCADA configuration, historian, and audit records can mean days of blind operation and months of rebuilding compliance evidence. This guide covers what a real SCADA backup and disaster recovery program looks like - RPO and RTO targets per data class, backup validation, ransomware-resistant architecture, the cloud shared-responsibility split, retention and export rights, and the restore drills that turn a backup from a hope into a plan.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
Classic disaster recovery planning assumed accidents: a failed hard drive, a flooded server room, a fat-fingered delete. Backups sat on a NAS down the hall, and that was fine, because the disaster was never going to log in and delete them. Ransomware broke that assumption. Modern intrusion crews spend days or weeks inside a network before detonating - mapping systems, stealing credentials, and specifically locating and destroying backups so the victim has no alternative to paying - the playbook CISA's Stop Ransomware guidance is built to defeat. Shadow copies get purged, network shares get encrypted, and backup servers joined to the same Windows domain get taken down with everything else.
Industrial operators have learned this the hard way. The most publicized incidents - Colonial Pipeline among them - showed that even when the control system itself is not encrypted, operators shut down because they lose confidence in the systems around it and cannot quickly prove what state anything is in. Recovery timelines in industrial ransomware cases are routinely measured in weeks, not hours, and the operators who recover fastest are consistently the ones who had isolated, validated backups and had actually practiced restoring them.
The consequence for your DR program is simple to state and demanding to implement: backups must be isolated from production credentials so an attacker cannot reach them, validated so you know they are intact and free of the intrusion itself, and drilled so restore time is a measured number rather than a guess. Everything else in this guide hangs off those three properties. For the broader attack-side picture, see our guide to ransomware protection for industrial operations.
Recovery point objective (RPO) is how much data you can afford to lose, measured backward in time from the moment of failure. An RPO of 15 minutes for your historian means that after a disaster, you accept that the last 15 minutes of process history may be gone. Recovery time objective (RTO) is how long you can afford to operate without the system before it is back - both terms formalized in NIST SP 800-34, the federal contingency planning guide. The two are independent: you can have a near-zero RPO (continuous replication) and still take two days to restore, or restore in an hour while losing a full day of data.
The mistake most operators make is setting one RPO and RTO for "the SCADA system" as a whole. In practice, different data classes have very different tolerances. Most facilities can run the process locally for hours without central dashboards - PLCs keep controlling - but cannot tolerate losing alarm delivery for long, and cannot afford to lose compliance records at all. Set targets per class:
| Data Class | Change Rate | Typical RPO Target | Notes |
|---|---|---|---|
| Platform configuration (tags, screens, alarm rules) | Low - changes with projects | After every change; 24h worst case | Small, cheap to back up, catastrophic to lose. Version it. |
| Historian / telemetry data | Continuous | Minutes | Needs replication or frequent incrementals; gateway store-and-forward covers data in flight. |
| Users, roles, permissions | Low | Daily | Restoring access control wrong reopens the door you just closed. |
| Audit trail and alarm/event history | Continuous, append-only | Near zero | Regulators and insurers ask for this first. Tamper-evident storage matters. |
| PLC / RTU programs and device configs | Rare - changes with MOC | After every management-of-change | Outside the SCADA platform, but the same DR plan must own it. |
RTO deserves the same decomposition. Ask: how long can we run without remote visibility? Without alarming? Without the ability to make setpoint changes remotely? Those answers - not a generic "four hours" - should drive your architecture and your vendor contract.
A complete SCADA backup inventory is longer than most operators expect. Walk through it once and write it down:
The most common DR failure mode is not missing backups - it is backups that were running for years and turn out to be unusable: silently truncated archives, a database dump that references an encryption key nobody exported, a job that has been failing since an upgrade eight months ago while its status email went to a departed employee's inbox.
Validation happens at two levels. Archive validation is automated: every backup archive is integrity-checked - checksums verified, structure parsed, completeness confirmed against expected contents - and failures raise alerts, not log lines. Restore validation is procedural: on a schedule, a human (or better, an automated pipeline) restores the backup into an isolated environment and verifies the result - tag counts match, screens render, alarm rules fire, users can log in, audit history is intact.
This is a fair place to say how Merobix handles it: the platform validates backup archives and maintains controlled restore tooling, so restores are a governed operation with a defined procedure rather than an improvised database surgery. Merobix is also building regular restore and failover exercises into its continuous validation program - because a vendor's restore capability, like yours, is only as real as its last drill. When you evaluate any vendor, ask for the date and outcome of their most recent restore exercise, not just a description of their backup schedule.
The 3-2-1 rule is the floor: three copies of your data, on two different media or systems, with one offsite. Against ransomware, add two more properties:
For OT specifically, there is one more architectural point: your backup path should not weaken your network segmentation. A backup server that needs inbound access into the OT zone is a new conduit for the attacker. This is one more argument for outbound-only data flows - the same principle behind the outbound-only gateway architecture that removes inbound firewall rules from the OT boundary entirely.
Moving to cloud SCADA changes who does the work, not whether the work exists. The vendor operates the platform infrastructure, so platform and historian backups, redundancy, and failover become their job - typically executed with far more automation and discipline than a single plant IT team can sustain. But three responsibilities stay with you no matter what the vendor does:
Resilience in cloud SCADA also starts before the backup layer. The Merobix architecture accepts telemetry durably before historian processing - data is not lost if a downstream component hiccups - and the gateway buffers with store-and-forward during connectivity outages, so an internet or platform interruption costs you latency, not data. Customer data-retention and export workflows let you pull your own copies on your own schedule. And if policy requires it, the platform can run on-premise or air-gapped, which moves the DR responsibility split - the cloud vs on-premise comparison covers that trade in detail.
Retention is where backup policy meets regulation. Pipeline operators, water utilities, and chemical facilities each face record-keeping expectations - audit trails, alarm histories, and operational records that may need to survive for years; water utilities, for example, must also maintain and periodically recertify risk and resilience assessments and emergency response plans under AWIA Section 2013. Set retention per data class, write down the regulatory driver for each period, and make sure your backup depth actually covers your retention promise: a seven-year retention policy backed by 90 days of backups is a finding waiting for an auditor.
Export rights deserve equal attention, because the quiet disaster nobody plans for is vendor offboarding. Before you sign with any cloud SCADA vendor, verify: Can you export your full configuration and historian in a documented, usable format? On demand, or only by support ticket? At what cost? What happens to your data after termination, and on what timeline is it deleted? Exercise the export path once during your evaluation - an export feature that has never been run is exactly as trustworthy as a backup that has never been restored. Our enterprise SCADA buyer's guide includes contract language for this.
A written DR plan that has never been executed is a first draft. Drills are what convert it into capability:
Key takeaway: A backup is a hypothesis; a restore is a fact. Ransomware crews target backups deliberately, so resilience means isolated copies that stolen credentials cannot delete, automated validation of every archive, and scheduled restore drills with measured RPO and RTO - from your own team and from your vendor. Demand restore evidence, not backup promises, from anyone who holds your operational data.
Take these into the evaluation. Good vendors answer them in specifics; weak vendors answer them in adjectives:
You can put these questions to Merobix directly - the security architecture page documents the platform's data-protection posture, and a guided demo is the right place to see export workflows and ask for restore-exercise specifics against your own requirements.
Backup frequency should follow the change rate of each data class, not a single schedule. Platform configuration - tags, screens, alarm rules, user roles - should be backed up after every change and at least daily. Historian data changes continuously, so it needs continuous replication or frequent incremental backups; a gateway with store-and-forward buffering also protects data in flight during outages. PLC programs change rarely but must be captured after every management-of-change event. Whatever the schedule, restores should be tested at least quarterly, because an unverified backup protects nothing.
RPO (recovery point objective) is the maximum amount of data you can afford to lose, measured backward in time from the failure - for a SCADA historian, an RPO of 15 minutes means you accept losing up to 15 minutes of process history. RTO (recovery time objective) is how long you can afford to be without the system before it is restored. OT operations often tolerate a longer RTO for dashboards than for alarming, and a near-zero RPO for compliance records. Set both numbers per data class, write them into your DR plan and vendor contract, and validate them with timed restore drills rather than assumptions.
Modern ransomware crews hunt backups first, so protection means isolation plus validation. Follow the 3-2-1 rule - three copies, two media types, one offsite - and make at least one copy immutable or offline so it cannot be encrypted or deleted with stolen administrator credentials. Keep backup-system credentials separate from your production domain, encrypt backup archives, validate archive integrity automatically, and run restore drills so you know the copies actually work. A backup that shares credentials and a network with the systems it protects will be encrypted right alongside them.
It is shared. The vendor is responsible for backing up the platform and historian infrastructure it operates; the operator remains responsible for PLC and RTU programs, local device configurations, and keeping independent exports of critical data. Get the vendor half in writing: RPO and RTO commitments, backup validation practices, and restore evidence. Merobix, for example, validates backup archives and maintains controlled restore tooling, supports customer data-export workflows so operators hold their own copies, and is building regular restore and failover exercises into its continuous validation program.
Restore into an isolated environment, never over the live system. A spare server, virtual machine, or non-production tenant lets you restore configuration and a slice of historian data, then verify tag counts, screens, alarm rules, user roles, and audit history against production. Time the exercise end to end - that measured number is your real RTO. Pair technical restore drills with tabletop exercises that walk the decision-making: who declares the disaster, who authorizes the restore, and how operations run during the gap. Quarterly configuration restores and an annual full DR exercise are a reasonable baseline.
Durable telemetry acceptance, store-and-forward buffering, validated backup archives, and controlled restore tooling - ask us the hard DR questions against your own recovery targets.