Every SCADA system will eventually fail — a hard disk dies, an upgrade corrupts a database, a fire or ransomware encrypts the servers. The difference between an outage and a catastrophe is the backup and disaster recovery (DR) plan: what gets backed up, how often, where it lives, and how fast the system can be restored. SCADA DR planning is harder than IT DR because SCADA combines servers, controllers, configuration, and a live process that keeps running — but it is exactly the discipline that most plants defer until the first loss.
What Must Be Backed Up
A complete SCADA restore needs five categories, and missing any one breaks the recovery:
- Configuration and projects — the SCADA project files, templates, and screen definitions; the development environment and its licenses.
- Databases — the historian's data files, the alarm/event database, and any SQL databases (with their schema and version).
- Controller logic — PLC/DCS program files, tag databases, and the exact firmware/version they run; restore of a controller needs the matching revision.
- System and platform — OS images or at minimum the base installation, drivers, and patches — rebuilding a Windows server from scratch costs days; an image costs hours.
- Credentials and keys — the certificates, service accounts, and connection strings the system uses; stored in a secure vault, not in the backup that anyone can restore.
Backup Strategy
| Layer | Frequency | Retention | Notes |
|---|---|---|---|
| Configuration/project | After every change (or daily) | ≥ 12 months with version history | Version control is a backup; check the project out of the VCS and it is restorable. |
| Historian/event data | Daily incremental, weekly full | Matches the data retention policy | Continuous archiving to a second location is better than periodic copies. |
| Controller logic | After every change; baseline at startup | Indefinite | Controller changes without backup are the most common silent data loss. |
| OS images | Quarterly or after major change | ≥ 2 generations | Combine with the patch/update record to rebuild exactly. |
Backups must be verified by restore: a backup that has never been restored is a hope, not a plan. Quarterly restore drills (at least the configuration and database layers) find the broken pieces — tape errors, missing licenses, wrong passwords — while there is time to fix them.
Offsite and the 3-2-1 Rule
The classic rule applies to SCADA with a twist: three copies, two media, one offsite. The twist: offsite copies must respect the OT security model — the backup transfer is itself a network path that must be authenticated and monitored, and the backup repository (often cloud) is a new party in the supply chain. Choose the offsite target deliberately: a second site, or a cloud repository with clear access control, and encrypt the backups in transit and at rest. Also consider: a ransomware attack will try to delete backups; immutable or air-gapped copies defeat it.
Disaster Recovery Plans and Tests
The DR plan is a document with: the failure scenarios (server loss, whole-site loss), the recovery objectives per system (RPO — how much data may be lost; RTO — how fast it must be back), the restore procedures step by step (with the actual tools and paths), the contact list (who restores, who decides, who communicates), and the decision authority (when to declare disaster and invoke DR). Test the plan annually end to end — full restore on spare hardware — plus quarterly partial tests. The DR test's purpose is discovering the plan's gaps while they are free.
SCADA-Specific Recovery Considerations
- The process does not wait — while servers restore, the process must be runnable: define the degraded-operations mode (operator local panels, manual control) and train it; DR is not only about servers, it is about keeping the plant safe and controllable.
- Historian gaps — after a disaster, the data between the last backup and the failure is lost by definition; the recovery plan must state how this is communicated to compliance/reporting (e.g., documented data gap notices).
- Version consistency — restore the configuration with the controller revisions it belongs to; mixing revisions is how restore projects create new faults.
- Security after restore — restored systems have the vulnerabilities of their backup age: patch policy must be applied to restored images before reconnection, and certificates/keys rotated if the backup medium was compromised.
Summary
SCADA DR is: back up everything needed to restore (config, data, logic, platform, credentials), on a schedule matched to change rates, with verified restores and offsite encrypted copies; plan the recovery with RPO/RTO and step-by-step procedures; and test the plan annually. The investment is small against the cost of one unrecoverable historian or one week of manual operation. Backup discipline is the cheapest insurance in automation — and the most often deferred.