Can you actually restore the ERP? Backup restore testing for manufacturers and plants

"Backup completed successfully" answers the wrong question

Ask most manufacturers whether their ERP is backed up and you will get a confident yes. There is a nightly job, it sends a green email, and nobody has thought about it since the server was installed.

That email tells you a copy of some data was written somewhere. It does not tell you whether your team could take that copy and get the plant scheduling, receiving, and shipping again before the end of the shift. Those are different questions, and the only way to answer the second one is to actually restore something and use it.

This post walks through what a real ERP restore involves, who should set the targets, and how to test it without taking production down.

What "restore the ERP" actually means

The ERP is rarely one thing. In a typical plant it is a web of pieces that all have to come back, in the right order, talking to each other:

• The database that holds jobs, inventory, orders, and costing
• The application and report servers that sit in front of it
• Licensing, sometimes tied to a specific server name, hardware ID, or a license server of its own
• Identity: the domain controllers, DNS, and accounts people use to log in
• Integrations: EDI with customers, shipping and label printing, shop floor data collection, MES, barcode scanners, and the connection to your accounting system
• Engineering data that the ERP points to, like a PDM vault or the file shares holding drawings and attachments
• Configuration that lives in someone's head: custom reports, print setups, scheduled jobs, and the one script that runs the overnight MRP

You can have a perfect copy of the database and still be down for days because the license will not activate on new hardware, the label printers point to a server name that no longer exists, or the only person who knows how the EDI mapping was set up retired last spring.

A good test is to ask: if the server room were gone tomorrow, what is the full list of things we would need, and where is each one coming from?

Two numbers the business should set, not IT

Recovery planning comes down to two targets. Neither one is a technical decision.

How long can you be down? This is your recovery time objective. Can the floor run off printed travelers for a shift? A day? What happens to shipping, receiving, and customer commitments after that?

How much work can you afford to redo? This is your recovery point objective. If you restore last night's backup, everything entered today is gone: receipts, completed operations, shipments, time entries. Is reentering a day of transactions acceptable, or does it need to be an hour?

The owner, the operations leader, and whoever runs finance should answer these. IT's job is to tell you what each answer takes and whether the current setup can meet it. The mismatch between what leadership assumes and what the backup system can actually deliver is usually where the real risk sits.

Backups an attacker cannot reach

Hardware failure is not the only reason you restore. Ransomware crews know backups are the thing standing between them and a payment, so they go looking for them.

CISA's #StopRansomware Guide tells organizations to maintain offline, encrypted backups of critical data and to regularly test the availability and integrity of those backups in a disaster recovery scenario. It explains that offline matters because many ransomware variants try to find and delete or encrypt any backups they can reach.

In plain terms, a few questions worth asking:

• Can someone who has taken over a normal admin account also delete or overwrite the backups?
• Is at least one copy offline, or locked so it cannot be changed for a set period?
• Is that copy somewhere other than the building the servers are in?
• Are backup consoles protected with MFA and separate credentials?

The same guide notes that if a third party or MSP maintains your backups, you should make sure they are following those practices. Outsourcing the job does not outsource the responsibility for knowing it works.

How to run a restore test without stopping the plant

A restore test does not mean pulling the plug on production. Done right, the plant never notices.

1. Pick a restore point. Use a real backup from your normal schedule, not one taken specially for the test.
2. Restore into an isolated environment. A separate network segment or a sandbox where the restored servers cannot reach production, send EDI to customers, or post to the live accounting system.
3. Bring up the pieces in order. Identity first, then the database, then the application, then the integrations you can safely test.
4. Have a real user use it. Not IT clicking around. Ask someone from the floor or the office to look up an open job, print a traveler, post a receipt, and run a report they use every week. If it is safe in your setup, run an MRP pass.
5. Time every step. Write down when you started and when each piece was usable. Compare that to the downtime target the business set.
6. Write down every surprise. The missing license key, the hard-coded server name, the password nobody had. Those notes are the point of the exercise.
7. Tear it down cleanly so the test copy does not become an unmanaged second ERP.

The first test almost always turns up something. That is good news. Finding it on a Tuesday afternoon is far better than finding it during an outage.

Write the runbook while you test

The test is also the best time to build the recovery runbook, because you are doing the steps for real. Capture:

• The order systems come back in, and who does each step
• Where license keys, vendor support numbers, and software installers are kept
• Software versions and patch levels, since a restore onto a newer version can fail
• How to reach the ERP vendor or reseller after hours
• Which integrations need to be paused or redirected so the restored system does not send duplicate orders or invoices

CISA's guide also recommends keeping offline backups and physical hard copies of IT documentation on site. If the runbook lives only on the server you are trying to restore, it will not help.

How often to test

There is no single right number, but some practical triggers:

• After any ERP upgrade, server move, or major configuration change
• When the person who owns the ERP changes
• When your recovery targets change
• On a regular calendar, with a full restore at least once a year and smaller file and database spot checks in between

The goal is that restoring becomes a routine task with a known duration, not a one-time project.

A note for DoD suppliers

If your ERP or file shares hold Controlled Unclassified Information, the backups hold it too. NIST SP 800-171 includes a requirement to protect the confidentiality of backup CUI at storage locations (3.8.9 in Rev 2), so the backup target, any offsite or cloud copy, and the people who can access them belong in your scoping. Dated records of your restore tests are also useful evidence that your recovery process actually runs, rather than living only in a policy.

Questions to ask this week

If you run the company or the plant, these are fair questions for whoever manages your IT:

• When did we last restore the ERP, and did a real user log in and work in it?
• How long did it take, and how long can we actually afford to be down?
• How much data would we lose if we restored last night's backup?
• Could an attacker with admin access delete our backups?
• Where is the recovery runbook, and could someone other than you follow it?

If the answers are vague, that is your starting point.

Where to go from here

Our IT Resilience Framework lays out how we think about recovery as part of day-to-day operations, and the manufacturing page covers the plant-specific side. If you want an outside look at where your environment stands today, the free 14-day IT Health Check is a low-commitment way to get a scorecard. And if you would rather talk through your recovery targets and what a first restore test would look like, you can book time with our team.