A backup you have to remember to run is a backup you will eventually forget, and the day you forget is usually the day you need it. Scheduling turns backups from a hopeful habit into a dependable machine that captures your SCADA system on its own, night after night, whether or not anyone is thinking about it. But a good backup strategy is more than picking a nightly time; it is a set of deliberate choices about what to protect, how far back to keep it, where to store copies so a single disaster cannot take them all, and, most neglected of all, whether the backups actually restore. This guide walks through scheduling recurring backups end to end: deciding what to capture, setting frequency and retention that match how fast your data changes, placing at least one copy somewhere a local fire or ransomware cannot reach, and scheduling a periodic restore test so you learn your backups work before you are betting the plant on them.
How to schedule a backup in SCADA in one line: To schedule a backup in SCADA, decide what to capture, at minimum the configuration, plus the historian and alarm logs if you need to reconstruct history, then set a frequency and retention that fit how fast each of those changes. Direct at least one copy to an offsite or immutable destination so a local fire, theft, or ransomware attack cannot destroy every copy, following the principle of keeping multiple copies on more than one medium with one held offsite. Most importantly, schedule a periodic restore test, because a backup nobody has ever restored is only an assumption, not a safety net, until it is proven.
Before you schedule anything, you have to decide what a backup should contain, because a SCADA system holds several very different kinds of data that change at very different rates and matter for different reasons. The configuration is the first and most important: the tag database, the screens, the alarm setups, the reports, the users and roles, everything that defines how the system is built. Losing the configuration means rebuilding the entire system from scratch, which can be weeks of work, so the configuration is the one thing every backup strategy must capture. It changes whenever an engineer edits the system, which is relatively infrequently but at unpredictable times, so it benefits from being captured both on a schedule and right after significant changes.
The historian, the store of logged process values over time, is the second kind of data, and it has a completely different character. It grows continuously as new samples are logged, it can be very large, and losing it means losing the historical record you rely on for trends, reports, reconciliation, and analysis. Whether and how often you back it up depends on how much history you can afford to lose and how much of it changes, since old historian data does not change once written while new data accumulates constantly. Alarm and event logs are a related third category, the record of what alarmed, when, and who acknowledged it, which matters for troubleshooting, compliance, and understanding past upsets, and which likewise grows over time.
Being explicit about these categories keeps a backup from being either useless or wastefully huge. A backup that captures only the configuration restores a working system but with no history, which may be fine for a quick recovery but loses the records. A backup that tries to capture everything on every run may be enormous and slow. The practical answer is usually to back the configuration up frequently because it is small and irreplaceable, and to back the historian and logs up on a cadence that balances how much history you can lose against the storage the copies consume. Naming exactly what each scheduled backup includes is the first decision, and it drives every setting that follows.
Frequency answers how often a backup runs, and the right answer follows from how much work you can afford to lose, the window between the last good backup and a failure. If the configuration is backed up nightly, a failure could cost up to a day of configuration changes, which is usually acceptable since configuration changes are infrequent, but a site making heavy edits might back up more often or on every change. Historian frequency is a similar calculation against how much recent process history you could stand to lose. The goal is not to back up as often as possible, which wastes storage, but to match the frequency to the pace and value of what each backup contains.
Retention answers how long you keep old backups before deleting them, and it exists because the most recent backup is not always the one you want. Some problems, a corrupted configuration change, a bad edit, a slow-spreading data corruption, are not noticed for days or weeks, by which point every recent backup already contains the problem. Keeping a series of older backups, a few daily, several weekly, some monthly, gives you a clean point to roll back to from before the problem started. Retention is the setting that lets you recover from mistakes you did not notice immediately, not just from outright hardware failure, which is a distinct and common kind of loss.
The destination is where the copies actually live, and this is where a scheduled backup either protects you or quietly fails to. A backup stored only on the same machine or the same site as the original is worthless against the disasters that matter most: a fire, a flood, theft, or a ransomware attack that encrypts everything it can reach, including local backups. The long-standing rule of thumb is to keep multiple copies on more than one kind of medium with at least one copy held offsite, so no single event can destroy them all. Increasingly important is immutability, storing at least one copy in a form that cannot be altered or deleted for a set period, which is specifically what defeats ransomware, since an attacker who reaches your backups cannot encrypt or wipe an immutable copy. Directing your scheduled backup to an offsite, ideally immutable, destination is what turns it from a convenience into genuine protection.
The single most neglected part of any backup plan is proving the backups actually restore, and it is neglected precisely because everything looks fine until the day you need it. A backup job that reports success every night can still be producing files that are incomplete, corrupted, or missing a piece you would need to rebuild, and you will not know until you try to restore and fail, which is the worst possible moment to discover it. The only cure is to schedule a periodic restore test: on a regular cadence, take a backup and actually restore it, into a test environment or a spare system, and confirm you get a working system back. A backup you have never restored is an assumption, and the restore test is what turns it into a fact.
The restore test also validates the human side of recovery, not just the files. It reveals whether the person on shift when disaster strikes actually knows the steps, whether the documentation is current, whether the restore takes an hour or two days, and whether any dependency, a license, a key, a driver, was left out of the backup. Discovering these gaps during a calm scheduled test is cheap; discovering them during a real outage with the plant down is expensive and stressful. Running the test regularly, and treating any failure as a real problem to fix, is what keeps the backup strategy honest as the system evolves and new components are added that the old backup job may not be capturing.
Where backups live and who maintains them changes when SCADA moves to the cloud, and it can shift much of this burden off the local team. With a cloud SCADA platform such as Merobix, the configuration and the historized data live on the hosted platform rather than on a workstation at the site, so the provider handles the redundant, offsite storage and the ongoing backup of the central system, which removes the very failure that sinks so many self-hosted sites, the single local server whose only backup sat on a disk in the same room. This does not eliminate the responsibility to think about backups, since you should understand what the provider retains and how you would export or recover your own data, but it does mean the hardest parts, offsite copies and continuous protection of a large historian, are handled for you rather than depending on a scheduled job someone has to babysit.
At minimum it must include the configuration, the tag database, screens, alarm setups, reports, and users and roles, because losing that means rebuilding the whole system from scratch. Beyond that, back up the historian if you need to keep the historical process record for trends and reports, and the alarm and event logs if you need them for troubleshooting or compliance. These change at different rates, so the configuration is usually backed up frequently while the larger historian is captured on a cadence that balances lost history against storage.
A backup stored only on the same machine or site as the original is worthless against the disasters that matter most, a fire, flood, theft, or a ransomware attack that encrypts everything it can reach, including local backups. The rule of thumb is to keep multiple copies on more than one medium with at least one held offsite. An immutable copy, one that cannot be altered or deleted for a set period, specifically defeats ransomware, because an attacker who reaches your backups still cannot destroy that copy.
Because a backup job that reports success every night can still be producing files that are incomplete or corrupted, and you will only find out when you try to restore and fail, at the worst possible moment. A scheduled restore test, where you actually restore a backup into a test system and confirm you get a working result, turns the backup from an assumption into a proven fact. It also validates the recovery steps, the documentation, and that no dependency like a license or key was left out.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.