Backup and operational continuity in factories: what to test in autumn

October is the golden month to test what cannot fail. While production carries on at its own pace, most Portuguese factories leave operational continuity for "when there's time" — and then, when the server goes down or the ERP becomes unavailable, they discover that the backup is unusable or that recovery takes 14 hours. In 2024, CERT.PT recorded 2,758 cybersecurity incidents in Portugal, a 36% increase compared to 2023; around 78% occurred in private entities. In SMEs, ransomware was present in 88% of the data breaches analysed — and most of those factories had not tested the recovery of their backups. This guide gives you a checklist of 18 practical tests, executable in 4 weeks, which turn your backup strategy from theoretical into operational.

What you need before you start

Before any test, gather three things: the complete inventory of critical systems (ERP, WMS, MES, accounting, email, shared files, customer database), the continuity plan documentation with the RTO and RPO of each system, and an environment isolated from production — a virtual machine, a secondary server, or a staging cloud. Then, form a multidisciplinary team: IT, operations, finance, warehouse. Each tests their own domain. Schedule the tests outside peak periods (August, pre-Christmas, pre-Black Friday, pre-year-end). Obtain written authorisation from the CEO/CFO to interrupt non-critical systems. Finally, keep the contacts of backup and cloud providers at hand — you will need them if something fails during the test.

Step 1: Validate backup integrity

Before recovering anything, confirm that what is stored is genuinely usable. Many factories discover, in the middle of a crisis, that the backup is corrupted, incomplete, or that the chain of incremental backups broke weeks ago without anyone noticing. Check the date and time of the last successful backup of each critical system — if the timestamp is old or missing, it is a red flag. Confirm the size of the backup file: if it is abnormally small (a tenth of what was expected), it may be truncated. Run an integrity test (checksum, hash) if your backup software allows it — it is the difference between a backup that seems to be fine and a backup that is fine. Validate the chain of incremental backups: if the base backup is corrupted, the incrementals will be too, and you will recover old or inconsistent data. Document everything in a validation form — it serves as regulatory evidence later on.

Answer these four questions honestly. If the answer to any one of them is "No" or "Out of date", it is a vulnerability:

• Do all systems have scheduled automatic backups?
• Is there a minimum 30-day retention of historical backups?
• Is the backup stored outside the local datacentre (offsite or cloud)?
• Is there documentation on how to restore each system, and has it been updated in the last 6 months?

Step 2: Test ERP recovery in a staging environment

The ERP is the heart of the factory. If it goes down, production does not know what to do, the warehouse cannot dispatch, and accounting is suspended. Test recovery with real data, not with synthetic test data. The difference is crucial: test data does not reveal the failures that real data reveals.

Restore the most recent ERP backup onto a virtual machine or staging server. Let it start up completely — do not interrupt the process. When it is ready, check that all modules start: finance, purchasing, production, sales, planning. If a module fails, the test failed — document the exact error. Run a test transaction in each module: create a purchase order, confirm a production order, post a purchase receipt. This is not cosmetic — it is proof that the ERP is operational. Validate data integrity: compare the number of records (customers, suppliers, products, open orders) with the production database. If records are missing or there are duplicates, the backup is compromised. Test the connection to peripheral systems: WMS, CMMS, Qlik Sense, if they exist. A failure in an integration is as serious as a failure in the ERP — the information flow breaks. Measure the actual real-time recovery time, from the restore command until the ERP is operational and accepting transactions. Compare it with the RTO: is it within range? If not, your continuity plan is illusory.

• Backup restored without errors?
• Do all modules start?
• Do test transactions work?
• Data integrity validated — does the number of records match?
• Do integrations with peripheral systems work?
• Actual recovery time: _____ minutes (vs. RTO of _____ hours — is it within range?)

Step 3: Test the recovery of critical data (warehouse and production)

Many managers focus on the ERP and forget the data that lives outside it: planning files in Excel, product specifications in PDF, production histories in spreadsheets, negotiated price lists, customer contracts. If these disappear, the factory is paralysed — the ERP may be working perfectly, but no one knows what to manufacture, nor to what specifications, nor at what price.

Identify the critical files: production plans (Excel, APS), technical specifications (PDF, CAD), quality histories, VIP customer lists, price contracts, process documentation. Then, confirm that they are included in the backup — often they are not, because they live in forgotten network shares, on local disks of old computers, or in unsynchronised cloud folders. Restore a batch of files from 1 month ago into a test folder. Open them and validate: does the file open? Is it complete? Is the data legible? If you use Document Management (UpgrAIde), test the recovery of archived documents — it is common for the archive to be included in the backup, but not the decryption keys. Test the recovery of critical emails, if the email server is included in the backup. Many factories lose customer orders because the email backup failed.

• Planning/production files recoverable and legible?
• Technical specifications and CAD recoverable and with integrity intact?
• Customer and supplier database recoverable?
• Quality/non-conformity histories recoverable?
• Archived documents (if you use Document Management) recoverable?
• Recovery time for a critical file: _____ minutes

Step 4: Test database failover (if you use replication or hybrid cloud)

If your ERP is replicated to a hybrid cloud or to a secondary server, automatic failover is only as good as the last test you performed. Many organisations discover, during an actual failure, that failover does not work because replication was interrupted months ago, or because the network settings changed and no one updated the plan.

Simulate a failure of the primary server: disconnect the machine from the network or switch it off (at a time agreed with IT and operations — do not do this without warning). Observe whether automatic failover occurs — how long does it take? If it takes more than a few minutes, your RTO is compromised. Confirm that the client applications (production terminals, KORA Productivity, sales force) automatically reconnect to the secondary server. If the workers have to reconfigure them manually, the failover is useless. Test a transaction on the secondary server: can you create a production order? Can you register a material receipt? If so, the failover worked. If not, the test failed. Check that there is no data loss between the last backup and the failover (RPO) — if the primary server went down 5 minutes after the last backup, you lost 5 minutes of data. Is that acceptable? Reactivate the primary server and confirm that replication resumes without conflicts. If there are data conflicts (the primary and the secondary have different versions of the same record), your continuity plan has a serious hole.

• Does automatic failover occur? If manual, how long does it take?
• Do client applications reconnect automatically?
• Do transactions work on the secondary server?
• Data loss between backup and failover — none, a few records, or significant?
• Does replication resume after reactivation of the primary without conflicts?

Step 5: Test access recovery (authentication and permissions)

A recovered backup is useless if no one can access it. Often, the access credentials, SSL certificates and encryption keys are not included in the backup — or they are, but have not been tested. A common scenario: the backup was made with administrator password A, but the password changed to B; the backup is recovered, but no one can access it because the password is A, and A is no longer valid.

After restoring the ERP or the database, try to access it with a normal user account (not administrator). Confirm that permissions are intact: a production worker sees only their own orders, a warehouse supervisor sees only their own warehouse, an accountant cannot access production data. If permissions are lost, the backup is incomplete. Test remote access (VPN, if applicable) — can you access the ERP from outside the factory? Validate SSL certificates and encryption keys — if they expire during the backup, recovery will fail. If you use two-factor authentication (2FA), confirm that the backup tokens/keys are stored and recoverable. Many organisations lose access because 2FA was enabled, but the backup keys were not included in the backup.

• Can normal users access after recovery?
• Are the permissions per profile intact?
• Does remote access work?
• Are SSL certificates valid? If not, in how many days do they expire?
• Is 2FA operational after recovery?

Step 6: Test the regulatory compliance of the backup

In Portugal, backup is not merely a technical matter — it is a regulatory one. The NIS2 Directive (Directive (EU) 2022/2555, transposed by Decree-Law No. 65/2025) extends cybersecurity obligations to medium and large companies across 18 critical sectors, including industry. One of the requirements is to keep backup copies and test them regularly. In addition, the GDPR requires that personal data (of employees, customers, suppliers) be protected even in backup.

Confirm that the backup includes personal data in encrypted form (GDPR). Validate that the offsite storage location complies with Law 58/2019 (national implementation of the GDPR in Portugal). Document the recovery test — NIS2 requires proof that the continuity plan has been tested, and that proof is your test record. If you use a cloud or external backup provider, check their ISO 27001 certificate or equivalent. Confirm that the service agreement (SLA) specifies the RTO and RPO — and that the test proves they are achievable. Test compliance with the IT supplier audit: does your backup provider respond to security questionnaires? If not, it is a regulatory risk.

• Backup encrypted (in transit and at rest)?
• Offsite storage certified (ISO 27001 or equivalent)?
• Recovery test documented (for NIS2 audit)?
• Does the provider's SLA specify RTO/RPO and is it aligned with the test?
• Has the provider passed a security audit (ISO 27001, SOC 2, or equivalent)?
• Is personal data included in the backup in encrypted form?

Step 7: Test the recovery of email and communications

Email is often forgotten in continuity plans — until the day the mailbox goes down and no one can send orders, order confirmations, or delivery notices. Restore an email backup onto a test machine. Confirm that the mailboxes start, that users can access them, and that old emails are recoverable. Test the recovery of a specific email from 1 month ago — can you find it? If the email server is integrated with the ERP (for example, to send invoices automatically), test that integration too.

Step 8: Test the recovery of third-party applications

If you use KORA Productivity, KORA Sales Suite, Qlik Sense, or other critical applications, test the recovery of each one. Often, the ERP backup is tested, but the backup of the peripheral applications is forgotten. Restore the application, confirm that it initialises, and test a critical function: in KORA Productivity, can you register a production run? In Qlik Sense, can you load a dashboard?

Step 9: Document and communicate the results

After each test, create a report. Not a consulting report — an operational report: what was tested, the result (passed/failed), how long it took, and what needs to be corrected. Share it with the operations team, IT, and management. If a test failed, set a deadline to correct it — and test again. If all the tests passed, congratulations — but repeat this exercise every 6 months. Operational continuity is not a project; it is a continuous process.

Frequently asked questions

What should I test first in my backup plan?

Start with the validation of backup integrity. Check the date and time of the last successful backup of each critical system, confirm the file size (if it is abnormally small it is a warning) and run a checksum or hash test. This reveals whether the backup is genuinely usable before attempting any recovery.

What is the difference between testing with real data and synthetic data?

Real data reveals failures that synthetic data conceals. When you restore the ERP in staging, use the backup with genuine production data. This allows you to validate whether all modules (finance, purchasing, production, sales) start correctly and whether the integrations with peripheral systems work.

How many weeks do I need to run the continuity tests?

The guide presents a checklist of 18 practical tests executable in 4 weeks. Schedule them outside peak periods (August, pre-Christmas, pre-Black Friday, pre-year-end) and obtain written authorisation from the CEO/CFO to interrupt non-critical systems during the tests.

What critical elements should I include in the systems inventory?

Include the ERP, WMS, MES, accounting, email, shared files and customer database. In addition, identify data outside the ERP: production plans in Excel, technical specifications in PDF, quality histories, VIP customer lists and price contracts — often forgotten in backups.

Who should be part of the test team?

Form a multidisciplinary team with IT, operations, finance and warehouse. Each department tests its own specific domain. This ensures that recovery is validated across all operational contexts, not just at a technical level.

How do I know whether my recovery time is within acceptable limits?

Measure the actual recovery time from the backup until the system is operational and accepting transactions. Compare this time with the RTO (Recovery Time Objective) documented in your continuity plan. If the actual time exceeds the RTO, your plan is illusory and needs adjustments.

What documentation do I need before starting the tests?

Gather the complete inventory of critical systems, the continuity plan documentation with the RTO and RPO of each system, and have an environment isolated from production (a virtual machine, a secondary server or a staging cloud). Also keep the contacts of backup and cloud providers at hand.

Sources

• CERT.PT — Report on Cybersecurity Incidents in Portugal 2024 (National Cybersecurity Institute)
• Directive (EU) 2022/2555 (NIS2) — Security of Network and Information Systems
• ISO/IEC 27001:2022 Standard — Information Security Management Systems
• ISO/IEC 27035:2023 Standard — Information Security Incident Management
• ENISA — Guidelines on Backup and Disaster Recovery (European Union Agency for Cybersecurity)