Manufacturing and Industrial Data Recovery: SCADA, MES, PLC, and ERP Systems

Over the past decade, manufacturing has arguably felt the impact of digital transformation more deeply than any other sector. The PLCs and HMI panels on the factory floor and the ERP systems on the office side used to be entirely separate worlds. Today, the SCADA historian database talks to the cloud, the MES sends real-time orders to the ERP, and a maintenance technician checks a PLC parameter from a tablet. This convergence has boosted efficiency, but it has also created an entirely new attack surface and a fresh set of data-loss scenarios. In an industrial company, a single disk failure or a ransomware incident can mean far more than lost files: it can bring the entire production line to a halt.

At DSET, in our lab at Hacettepe University Teknokent in Ankara, the most critical insight from the cases we handle out of the Bursa, Kayseri, and Kocaeli industrial zones is this: production data is not just another dataset, it is the factory's memory. In this article, we walk through the typical data-loss scenarios across the SCADA, MES, PLC, and ERP layers, real-world cases from around the globe, and our approach to recovery.

The IT/OT Divide: Why It Matters So Much

In a manufacturing environment, data lives in two large worlds. The IT (Information Technology) side covers classic enterprise systems such as office computers, email, file servers, and ERP. The OT (Operational Technology) side covers the systems that directly control production on the floor: PLCs, HMIs, SCADA, MES, and historians.

NIST SP 800-82 Revision 3 (csrc.nist.gov/pubs/sp/800/82/r3/final) is the reference document for ICS (Industrial Control Systems) security, and it explains in detail why the IT/OT separation must be preserved. The IEC 62443 series of standards (iec.ch/cyber-security) provides a comprehensive security framework for industrial automation and control systems. These standards are critical not only for security but also for data recoverability, because the backup strategy, storage architecture, and disaster-recovery approach differ completely between the two worlds.

The ISA-95 standard (isa.org) defines the integration between business and control systems. Its hierarchy, Level 0 (field devices), Level 1 (PLC), Level 2 (SCADA/HMI), Level 3 (MES), and Level 4 (ERP), is the same framework we use when planning data recovery. Each level carries different consequences when data is lost, and each calls for a different response.

SCADA Systems: The Importance of Historian Data

SCADA (Supervisory Control and Data Acquisition) systems collect dozens of data points per second from thousands of sensors on the floor. This data is stored in historian databases (OSIsoft PI System, GE Proficy, AVEVA Wonderware Historian). In a chemical plant, temperature, pressure, and flow data may be retained for years, because it is needed for process optimization, product traceability, and regulatory compliance alike.

The SCADA data-loss scenarios we encounter most often are:

The historian disk fills up and the database becomes corrupt. OSIsoft PI and Wonderware Historian use SQL Server or a proprietary time-series database on the back end. The moment a disk hits 100 percent, write operations are cut off mid-stream and some page structures get corrupted. On the next restart, the database either will not open or opens with only partial data.

The Siemens WinCC database collapses. WinCC is built on MS SQL Server Express, and when it hits the 10 GB ceiling the database stops growing. When that limit goes unnoticed, alarms and trend records are lost silently.

Rockwell FactoryTalk projects become corrupt. When .ACD and .APA project files are kept without version control, a single bad save can wipe out weeks of production tracking at a plant.

In these scenarios, our work in the DSET lab is to first take a bit-level image of the disk, then attempt to open the SQL Server-based historian database using page repair, DBCC CHECKDB, and raw record extraction. Without a full backup strategy, accepting the loss of a portion of the data may be unavoidable, but the vast majority is usually recoverable. We covered the broader picture in our Data Recovery Guide 2026 Turkey article.

PLC Programs: No Backup Means No Recovery

In the PLC (Programmable Logic Controller) world, the most painful scenario is the program being lost on the floor. Devices like the Siemens S7-1200/1500 series, Allen-Bradley ControlLogix, Mitsubishi MELSEC, and Omron CJ/NJ hold the logic that controls the production line.

The typical case we see goes like this: a PLC running on a 10-year-old line fails. The backup program cannot be found on the engineering workstation, on a USB stick in the maintenance cabinet, or on the old machine. In some cases an online upload from the PLC is possible, but the comment lines, symbolic names, and the programmer's notes are gone. In other cases the PLC is password-protected, an upload is impossible, and it has to be rewritten from the factory nameplate.

This is why, in the world of industrial automation, a "no PLC backup, program lost" situation is far more dangerous than a hard-disk failure. PLC data does not sit on a disk; it lives inside the hardware. A data recovery lab can perform chip-level NAND reads in this case, but that is a very limited domain, and unless the device is physically inoperable it is usually wiser to rebuild the backup strategy.

MITRE ATT&CK for ICS (attack.mitre.org/matrices/ics) catalogs the attack techniques carried out against PLCs and SCADA. Techniques such as "Modify Program" and "Block Reporting Message" are risks worth understanding not only for security but for data integrity as well.

MES Databases: The Heart of the Factory's Memory

MES (Manufacturing Execution System) platforms hold operational data such as production orders, batch tracking, quality records, shift data, and OEE (Overall Equipment Effectiveness) metrics. Most MES solutions (Siemens Opcenter, Rockwell FactoryTalk ProductionCentre, GE Proficy Plant Applications, and local AVEVA and Turkish MES products) use SQL Server or Oracle on the back end.

When an MES database becomes corrupt, the last few weeks of batch traceability, quality measurements, and machine-downtime records are put at risk. In the pharmaceutical and food sectors these losses also create regulatory problems, because traceability is a legal requirement.

On the SQL Server side, when a database becomes corrupt, recovery is possible through DBCC CHECKDB, page-level repair, transaction log replay, and even record extraction from the raw .MDF file. We covered this in more detail in our RAID 5 Failure Recovery Process and Cost article, because MES servers very often run on RAID 5 or RAID 10 configurations, where disk failure and database corruption become intertwined.

ERP Systems: SAP, Oracle, Logo Tiger

ERP (Enterprise Resource Planning) systems (SAP S/4HANA, Oracle E-Business Suite, Logo Tiger, Mikro Run, IFS) are now the backbone for manufacturing companies. Inventory, production orders, costing, invoicing, and customer and supplier data all come together here.

In ERP data-loss cases we see three typical scenarios. The first is the failure of the RAID array that holds the Oracle or HANA database files. The second is the ERP server being encrypted by ransomware, in which case the first 24 hours after a ransomware attack: emergency response procedure must be put into action. The third is the database becoming corrupt during a botched update or migration.

On the Logo Tiger and Mikro side, corruption of SQL Server-based structures following an improper shutdown, disk failure, or software fault is a common case. Here too the basic approach is to first image the raw disk, then perform page repair on the .MDF/.LDF files and, where necessary, extract the data piece by piece.

Three Critical Cases From Around the World

To understand why a backup strategy is vital in manufacturing, three publicly documented cases are enough.

The Maersk NotPetya attack, 2017. The global logistics giant Maersk lost a large part of its global IT infrastructure as a result of the NotPetya malware. According to the company's own statement, the total cost was roughly 300 million USD. Maersk was able to rebuild its Active Directory infrastructure only because a single server in a Ghana office happened to be physically offline at the time. This case showed that geographically separate backups are not a theoretical concept but a life-saving practice.

The Norsk Hydro LockerGoga attack, 2019. The Norwegian aluminum producer was hit by the LockerGoga ransomware. The company decided not to pay the ransom and communicated transparently with the public. The estimated cost was around 75 million USD. What stands out about this case is that the company was able to restore from backups and avoided a total shutdown by dropping production processes into manual modes. Post-incident analyses found that the clean separation of OT from IT, and the fact that the plants were designed to run partly in manual mode, proved to be the saving grace.

The Honda factory shutdown, 2020. The Japanese automotive giant Honda was forced to halt production at several of its plants following an attack on its global IT infrastructure. The integrated architecture of the systems tied to the production lines showed how an incident on the IT side could directly affect the OT side.

The shared lesson of these three cases is clear: without a backup strategy, no matter how large you are, recovery is close to impossible. CISA ICS Advisories (cisa.gov/news-events/cybersecurity-advisories) publishes continuously updated security bulletins for industrial control systems, with new vulnerabilities added every month.

Backup Strategy: The 3-2-1-1-0 Rule

The backup strategy we recommend in manufacturing is the 3-2-1-1-0 model: three copies, two different media types, one copy offline, one copy immutable, and zero errors on verification. In this model:

• The SCADA historian gets a daily full backup plus hourly incremental backups
• PLC programs are automatically uploaded to the engineering workstation and a central repository on every change
• The MES database gets continuous backup at the transaction-log level plus an offline copy
• The ERP database uses immutable storage (similar to S3 Object Lock) plus cold storage
• Restore tests of the backups are run at least once per quarter, because simply taking a copy is not enough

The concept of an air gap is critical here. For a backup to be truly air-gapped means it cannot be reached over any network connection. The NotPetya case made it abundantly clear how important this is. Even so, "the air gap was broken" is a typical scenario. The moment an engineer copies a backup over USB, a temporary network bridge is set up, or a connection is opened during an update, the air gap effectively disappears.

Immutable backups have become a prominent topic in recent years. Ransomware groups now target backup servers first, because if they can delete the backups, the pressure to pay the ransom rises. Enterprise backup platforms such as Veeam, Commvault, and Rubrik try to close this attack surface with immutability and WORM (write once, read many) features. For critical systems like SCADA and MES in a manufacturing environment, these features are no longer optional but mandatory.

Cold storage refers to backups kept on media such as tape (LTO-8/LTO-9) or offline disks, stored in a vault or at a physically separate location. Many of the factories we see in the Bursa, Kayseri, and Kocaeli industrial zones still keep their annual archive backups on tape, and that can be the very thing that keeps a company standing in a NotPetya-like event.

Incident Response and KVKK Compliance

When a data-loss event occurs at a manufacturing company, it is not just technical recovery that must run; the incident response procedure must run too. Our Cyber Incident Response IR Playbook article, prepared with reference to NIST SP 800-61, offers a detailed framework that applies to manufacturing environments as well.

Under KVKK (Turkey's Personal Data Protection Law, kvkk.gov.tr), if a data-loss event touches a system containing personal data (for example, if personnel tracking is integrated into the MES, or customer data lives in the ERP), the Board must be notified within 72 hours. In the EU, the NIS2 directive imposes similar but stricter obligations on critical-infrastructure operators, and exporting industrial companies operating in Turkey may also be affected by this compliance regime as long as they ship products into the EU market.

The ISO/IEC 27037 standard (iso.org/standard/44381.html) provides guidance on the identification, collection, acquisition, and preservation of digital evidence. In our DSET lab, every case that involves incident response is documented with a chain of custody compliant with these standards.

Challenges Encountered in Manufacturing Cases

Data recovery in a manufacturing environment differs from office cases in several ways. First, the time pressure is extremely high. An automotive supplier plant generates hundreds of thousands of lira in revenue per hour, and every minute of downtime is a cost. Second, the system architecture is complex: the SCADA, MES, ERP, and PLC layers are interconnected, and corruption in one layer affects the others. Third, the documentation is usually incomplete: the PLC program was loaded onto the floor 15 years ago, three engineers have come and gone since then, and what remains is code with no comment lines.

At DSET, we act with these challenges in mind. For cases coming from industrial hubs such as Bursa, Kayseri, Kocaeli, Gaziantep, and Eskisehir, we offer an insured shipping process and, when urgent, same-day delivery to the lab by courier. Requests to send a technician on-site are also possible, but data recovery is a safer process with a higher success rate under lab conditions.

The DSET Approach

In our ISO 14644 Class 100 cleanroom lab at Hacettepe University Teknokent in Ankara, the path we follow on manufacturing and industrial cases is:

1. A bit-level image is taken of the hardware that arrives from the field team or by shipping
2. The original media is never run directly; all work is carried out on copies
3. For a SCADA historian, MES database, or ERP structure, page-level analysis is performed on the appropriate database engine
4. In PLC cases, the remnants of engineering-workstation backups and the file-system metadata are scanned
5. The final report is documented in line with KVKK and ISO/IEC 27037

For cases coming from Bursa, Kayseri, Kocaeli, and other industrial zones, we operate an insured shipping process. We shared region-specific details in our Bursa Data Recovery and Kayseri Data Recovery articles.

Conclusion

In manufacturing, data recovery is not just a disk operation. Across a wide spectrum that runs from the SCADA historian to the PLC program, and from MES records to the ERP database, the chances of recovery drop dramatically without a sound backup strategy. The Maersk, Norsk Hydro, and Honda cases show us that preparation is a discipline to be carried out years in advance, not at the moment of the attack.

If you have experienced data loss on the SCADA, MES, PLC, or ERP side at your factory, contact DSET before restarting the system. Restarting a running system most often means overwriting recoverable data. Shipping to our Hacettepe Teknokent Ankara lab by insured carrier is possible from Bursa, Kayseri, Kocaeli, and every industrial zone.

Contact: You can reach our 24/7 emergency support line at +90 536 662 38 09 for an initial technical assessment. DSET, since 2003, Ankara Hacettepe Teknokent Beytepe; +90 536 662 38 09. Production data is the factory's memory; when that memory is lost, rebuilding it takes months. Working with the right team at the right moment can cut that time down to days.