SCADA teams lose data to failed drives, corrupted project files, and ransomware, and a single backup sitting on the same server rarely survives any of them. The 3-2-1 backup rule is a simple, memorable discipline that fixes this: keep three copies of your data, on two different types of media, with at least one copy stored offsite. Applied to SCADA project files, historian databases, and full server images, it turns a fragile single backup into a layered defense. This guide walks through each number, why the offsite copy is the one that saves you during a ransomware event, and how the rule maps to your recovery time and recovery point targets.
3-2-1 backup rule in one line: The 3-2-1 backup rule says you should keep three copies of your important data, stored on two different media types, with at least one copy kept offsite. For SCADA, that means the live system plus two backups of the project files, historian, and server images, with one backup held in a separate location so a fire, flood, or ransomware attack at the control room cannot destroy every copy at once.
The first number, three copies, counts the working data plus two backups. The live SCADA system on the server is copy one. A backup on a local disk or backup appliance is copy two. A third copy held somewhere else is copy three. The reason for three rather than two is straightforward: if the primary fails and you reach for your only backup and it turns out to be corrupt or incomplete, you have nothing left. A third independent copy means a single bad backup does not leave you empty-handed.
The second number, two media types, means the copies should not all live on the same kind of storage. If both your live data and your backup sit on spinning disks in the same rack, a controller fault, a power surge, or a firmware bug can take out both together. Spreading copies across different media - local disk plus a backup appliance, or disk plus cloud object storage, or disk plus tape - removes that shared failure mode. The point is that no single hardware defect or media flaw should be able to reach every copy you own.
The third number, one offsite, is the copy that survives a site-level disaster. A fire in the control room, a flood, a lightning strike, or a theft can destroy every device physically present. If one full copy lives in another building, another facility, or a cloud region far away, the loss of the site does not mean the loss of the SCADA configuration and history. This offsite copy is what turns a total-loss event into an inconvenient restore rather than a permanent gap.
For a SCADA environment, the data worth protecting falls into three broad buckets, and the 3-2-1 rule applies to each. The first is the engineering data: the SCADA project files, HMI screens, tag databases, alarm configurations, and PLC or RTU programs. These are the recipe for rebuilding the system, and they change whenever an engineer commits work, so they should be captured on a schedule tight enough that a day of engineering effort is never at risk. The second bucket is the historian database, which holds the accumulated process and measurement history that regulators, production accounting, and troubleshooting all depend on.
The third bucket is full server images: complete captures of the operating system, drivers, installed SCADA software, and configuration for the SCADA server, historian server, and engineering stations. These images let you rebuild an entire machine rather than reinstalling everything by hand under pressure. When you apply 3-2-1, each bucket gets its three copies spread across two media with one offsite, though the frequency differs - historian and project files may be captured nightly, while a golden server image is refreshed only when the build changes.
The crucial detail for OT is that at least one of those offsite copies should be air-gapped or offline rather than a live network share. A backup that is always mounted and reachable over the network can be encrypted by the same ransomware that hit the SCADA server, because the malware simply follows the connection. An air-gapped copy - one that is physically disconnected, on removable media rotated out of the building, or on immutable storage the attacker cannot write to - is the copy that is guaranteed to still be clean when everything reachable has been encrypted.
The 3-2-1 rule is a storage strategy, but it only earns its keep when it is tied to recovery targets. Your recovery point objective, the maximum data loss you can tolerate measured in time, sets how often each copy must be refreshed: if you cannot lose more than an hour of historian data, hourly capture of that copy is what the rule demands. Your recovery time objective, how long you can be down before restore, shapes which copy you reach for first - a fast local disk copy for a quick rollback, and the slower offsite or air-gapped copy only when the local copies are gone or compromised.
Restoring from a backup you have never tested is a gamble, so the rule works best when paired with periodic restore drills that prove each copy actually rebuilds a working system within the target time. A backup that exists but will not restore is not a copy at all. Drilling the offsite copy in particular matters, because it is the one you will lean on during the worst events, and the day of a ransomware outage is the wrong time to discover the archive was incomplete.
Cloud SCADA changes the arithmetic in a helpful direction. A platform like Merobix continuously streams field data into a managed cloud historian, which naturally provides a geographically separate copy of measurement history that is maintained and replicated for you rather than depending on a technician remembering to rotate a drive. That does not replace the whole rule - you still keep engineering project files and server images backed up under 3-2-1 - but it satisfies a large part of the offsite and second-media requirements for the historian automatically, so the history of remote well pads and metering sites is no longer trapped on a single box in a shed.
Yes, a cloud copy in a region separate from your site satisfies the offsite requirement, because a fire or flood at the control room cannot reach it. Just make sure it is also on a different medium than your local backup and, ideally, that at least one cloud copy is immutable or versioned so ransomware cannot overwrite it. A cloud share that stays continuously writable over the network is offsite but not automatically ransomware-proof.
Because backups fail silently. A backup can be corrupted, incomplete, or captured at a moment when the historian was mid-write, and you often do not discover that until you try to restore. With only one backup, a bad copy leaves you with nothing after the primary fails. A third independent copy means a single bad or unavailable backup does not end your recovery.
Modern ransomware deliberately hunts down and encrypts any reachable backup before triggering, so a backup on a live network share offers little protection. The offsite, air-gapped copy in 3-2-1 is the answer: a copy that is physically disconnected or held on immutable storage cannot be reached and encrypted, so it remains clean. That clean copy is what lets you rebuild the SCADA system without paying, and it is why the offline copy is the single most important part of the rule for OT.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.