When a SCADA server's disk dies, its motherboard fails, or ransomware renders the operating system unbootable, restoring just the SCADA project files onto a machine that no longer exists does no good. A bare-metal restore solves the whole-machine problem: it rebuilds an entire server - operating system, drivers, installed applications, and configuration - onto blank or replacement hardware from a full system image. This guide explains what a bare-metal restore captures and replays, why it beats an application-only config restore when the box itself is gone, the caveats of restoring to different hardware than the original, and why you validate the whole thing in a drill before you need it.
Bare-metal restore in one line: A bare-metal restore is a full recovery that rebuilds a complete server from a system-level image onto empty hardware, including the operating system, drivers, installed software, and all configuration - not just the application data. It is how you bring a dead or wiped SCADA server back to life on a replacement machine without reinstalling and reconfiguring everything by hand.
The phrase bare metal refers to hardware with nothing installed on it - no operating system, no software, just empty storage. A bare-metal restore takes such a machine and, from a full image, reconstructs everything needed to make it a working server again. The image was captured earlier at the system level, meaning it includes the operating system installation, the boot configuration, hardware drivers, the SCADA software and its patches, licensing artifacts, network settings, and the project data, all as one coherent whole. Replaying it produces a machine that boots and runs as the original did.
This is fundamentally different from an application-level restore that recovers only the SCADA project files, tag database, or historian and assumes a functioning operating system with the SCADA software already installed and configured underneath. A config-only restore is perfect when the machine is healthy and you just need to roll back a bad change or move a project. It is useless when the machine itself is the casualty, because there is no functioning host left to receive the configuration.
The restore is typically driven by boot media - a recovery USB or network boot environment that loads a minimal restore engine, connects to where the image is stored, and writes it back to the new disks before rebooting into the recovered system. Because the image captured the full disk layout and system state, the recovered server comes up with the correct operating system, drivers already in place, and the SCADA application ready to run, rather than requiring a technician to install an operating system, chase down drivers, reinstall the SCADA suite, reapply patches, and re-enter configuration under time pressure.
The cleanest bare-metal restore puts the image back onto hardware identical to the original, because the drivers and hardware assumptions baked into the image match perfectly. Reality is rarely that tidy. When a five-year-old SCADA server dies, the identical model is often no longer available, and the replacement has a different storage controller, network adapter, or chipset. Restoring an image onto hardware different from where it was captured is called a dissimilar-hardware or restore-to-different-hardware operation, and it needs extra care because the original drivers may not match the new devices.
The classic failure is a machine that will not boot after restore because the storage controller the operating system expects is not the one physically present, so it cannot even read its own disk. Good bare-metal restore tools include a dissimilar-hardware feature that injects the correct boot-critical drivers for the new machine during the restore, or that abstracts the hardware layer so the recovered system tolerates the change. Restoring a physical image into a virtual machine, a physical-to-virtual conversion, is a related path that sidesteps hardware matching by presenting the recovered system with standardized virtual devices.
Beyond drivers, a few caveats bite in practice. Disk geometry matters: the target disks must be at least as large as the originals, and layout differences can complicate the restore. Licensing tied to specific hardware may need reactivation on the new machine. Network identity, machine name, and domain membership have to be reconciled so the recovered server rejoins the environment cleanly rather than colliding with a still-registered ghost of the old one. None of these are showstoppers, but each is a surprise better discovered in a drill than during a real outage.
A full system image sitting in a backup repository proves nothing until it is restored and the result is exercised. The only honest test of a bare-metal restore is to actually perform one onto spare or virtual hardware, boot the recovered SCADA server, and confirm it does its job - connects to its field devices, resumes polling, serves the operator screens, and writes to the historian. A restore that boots to a login prompt but cannot reach the PLCs is a partial success that will not carry you through a real event, and only a drill surfaces that gap.
Drilling also produces the number that matters for planning: how long a full rebuild actually takes end to end, from blank hardware to a working control system. That measured time is what you compare against your recovery time objective. If the objective is four hours and a bare-metal restore honestly takes eight, you have learned something valuable before the crisis - perhaps you need a warm standby, a virtualized copy that can spin up faster, or a redundant server pair rather than relying on rebuild-from-image alone. Guessing this number is how sites discover the hard way that their recovery plan does not fit their downtime tolerance.
For distributed field operations, the appeal of a fast, proven bare-metal restore is obvious: the on-site SCADA server for a gas plant or a water district is often the single machine standing between operators and blindness to the process. Cloud SCADA shifts the exposure by moving the primary monitoring and history into a managed platform such as Merobix, so a failed on-site box no longer takes visibility down with it - the field data continues flowing to a dashboard reachable from any browser while the local server is rebuilt. The bare-metal image still matters for any on-premises component, but the operator's window into remote wells and pipelines does not go dark while the restore runs.
A PLC configuration backup restores just the controller's logic and settings onto a working, already-installed controller, and a SCADA config restore recovers only the project files onto a healthy server. A bare-metal restore rebuilds the entire server itself - operating system, drivers, software, and configuration - onto blank hardware. You use config restore when the machine is fine and only the application data is at risk, and bare-metal restore when the whole machine is dead or wiped.
Yes, but it requires a tool with dissimilar-hardware support that injects the correct boot-critical drivers for the new machine so it can boot from its own disk. Without that, the restored system often fails to boot because it expects the original storage controller. Restoring the image into a virtual machine is another way around hardware mismatch, since it presents standardized virtual devices. Either way, test it in a drill before you rely on it.
Refresh the image whenever the server's build changes - after operating system patches, SCADA software upgrades, driver updates, or significant configuration changes - rather than on a fixed calendar. The historian data and project files change often and are captured more frequently by their own backups, but the full system image only needs refreshing when the underlying machine state changes. A stale image that predates a major upgrade will restore an out-of-date server.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.