A backup that has never been restored is an assumption, not a recovery plan. For a manufacturer, the difference matters. If an ERP database cannot be brought back cleanly, a CAD file store is incomplete, or a production server takes days rather than hours to recover, the impact reaches far beyond the IT team. Orders stall, schedules become unreliable and people start working from spreadsheets.
Knowing how to test backup recovery gives you evidence that your business can continue after ransomware, hardware failure, accidental deletion or a site-level incident. The aim is not simply to prove that files exist in a backup console. It is to prove that the systems your operation depends on can be restored, accessed and used within an acceptable timeframe.
Start with the systems that stop production
Do not begin by trying to test every device and dataset at once. That usually creates an exercise so large it gets postponed. Instead, identify the systems whose loss would affect production, dispatch, purchasing, quality records or payroll.
For many engineering and manufacturing businesses, this includes the ERP or MRP platform, its database and application server, file shares holding drawings and programmes, email, finance systems, virtual machine hosts, and identity services such as Active Directory. It may also include a specialist application that communicates with a machine, label printer, warehouse scanner or shop-floor terminal.
Each system needs a named business owner, not only an IT contact. The production manager may be best placed to confirm whether a restored MRP system can create works orders. Finance should confirm whether accounting data is complete. This makes recovery testing a business continuity exercise rather than a technical box-ticking exercise.
Set recovery targets before the test
A useful test needs a pass or fail measure. Agree two targets for each critical system: the recovery time objective and recovery point objective.
The recovery time objective is how long the system can be unavailable before the disruption becomes unacceptable. A four-hour target for a core ERP service may be realistic; a two-day target may not be. The recovery point objective is how much data you can afford to lose, measured from the last usable backup. If the business can only tolerate one hour of lost transactions, a nightly backup is unlikely to meet the requirement.
These targets involve trade-offs. Shorter recovery windows and more frequent backups normally require more storage, more capable infrastructure and more planning. But setting targets based on operational reality prevents you from paying for backup that cannot protect the output it is meant to protect.
How to test backup recovery safely
The safest approach is to restore into an isolated test environment. You want to validate the backup without overwriting live data, interrupting users or accidentally allowing an old server to communicate with your production network.
This is particularly important where legacy operating systems, machinery interfaces or older applications are involved. A restored server may have the same name, IP address or credentials as a live system. It should be separated from production using network segregation, a controlled virtual environment or a dedicated recovery network. Disable outbound connections unless they are specifically required for the test.
Begin with a simple restore test, then progress to a full service recovery. A practical sequence looks like this:
- Select a recent backup and verify that it completed without warnings or missing protected items.
- Restore the required server, database, files or application into the isolated environment.
- Measure the time taken from starting the restore to making the service available.
- Ask the relevant users to sign in and complete normal tasks using the restored system.
- Record what worked, what failed, how much data was recovered and what needs to change.
A successful restore is more than a green completion message. A database can restore but fail to connect to its application. A file share can reappear with incorrect permissions. An ERP service can start while background jobs, integrations or licensing remain unavailable. Testing must follow the dependency chain, not stop at the first technical milestone.
Test data, applications and access together
For a file server, choose representative drawings, quality documents and production programmes. Confirm they open, versions are correct and the right groups can access them. Check that deleted files can be recovered too, as accidental deletion is a common real-world recovery scenario.
For ERP and MRP systems, restore a copy of the database and application components together where possible. Log in with a normal user account and test a small number of meaningful workflows. For example, search a stock item, view a bill of materials, open a works order and produce a report. If the platform exchanges data with finance, warehouse, CAD or shipping software, test the most critical integration in a controlled way.
For virtualised environments, do not assume that restoring a virtual machine proves the host-level recovery plan. Test whether critical virtual machines can be recovered in the required order, whether storage capacity is available and whether network configuration can be recreated. Domain services, database servers and application servers often need a specific start-up order.
Include ransomware and site-loss scenarios
A standard restoration test answers one question: can we recover a system? A stronger programme also asks: can we recover when the usual environment is unavailable or compromised?
Ransomware can encrypt live data and reach poorly protected backups. Test whether you have an immutable or offline copy, who can access it, and whether its retention period is sufficient. Check that backup administration accounts are protected with multi-factor authentication and are not shared with everyday user accounts. A recovery plan that depends on credentials stored on a compromised server is unlikely to work when needed.
At least annually, test a scenario where a major server, virtual host or office location is unavailable. This does not necessarily mean building a full disaster recovery site. It means understanding where you would restore, how long it would take to obtain replacement hardware or cloud capacity, and which services must come back first.
Manufacturing environments add another consideration: what happens at the boundary between office IT and operational technology? A recovery plan should not casually reconnect restored, older systems to machinery networks. Use documented network segregation, approved jump machines and vendor guidance. The priority is to restore production safely, not merely quickly.
Document the outcome, not just the process
A recovery test that lives only in the memory of the technician who ran it will not support your business during an incident. Record the date, systems tested, backup set used, people involved, start and finish times, validation steps and results.
Capture exceptions plainly. Perhaps the data restored correctly, but a licence key was held by a former supplier. Perhaps the server met its recovery target, but the application took another three hours to become usable. Perhaps the test revealed that a critical machine programme is stored locally rather than in the central backup scope. These findings are valuable because they identify risks while there is time to resolve them.
The document should also state the next action, owner and deadline. Recovery testing often exposes responsibilities spread across internal teams, software vendors and IT providers. Clear ownership prevents a known weakness from becoming an accepted risk.
Choose a recovery test schedule that reflects risk
Not every system needs a full recovery test every month. The right frequency depends on how critical the service is, how often it changes and how much confidence you already have in the backup design.
A sensible baseline is to test individual file and database restores monthly, test a critical application recovery quarterly, and run a broader disaster recovery exercise annually. Test again after major changes such as an ERP upgrade, migration to new servers, a change in backup platform, acquisition of a business unit or significant network redesign.
Compliance requirements may affect the evidence you retain, particularly if you work to ISO standards or handle controlled customer information. Even where a standard does not prescribe a precise testing interval, dated records of restore tests demonstrate that resilience is being actively managed.
Common recovery testing mistakes
The most common mistake is checking that backup jobs have completed and treating this as proof of recovery. Backup monitoring is essential, but it only confirms that a process ran. It does not confirm the recoverability, integrity or usability of the data.
Another mistake is testing only documents. Files matter, but the applications, databases, permissions and integrations around them are usually what keep the business moving. Finally, avoid testing against live production systems without a clear change plan. A poorly controlled restoration can create duplicate servers, conflicting records or unnecessary downtime.
A dependable recovery plan is built through repeatable tests, honest results and improvements that are owned through to completion. The most reassuring time to discover a gap in your backups is during a planned exercise, with production running normally and the right people available to fix it.
