Backup Succeeded. Can Your ERP Recover? A Restore Drill Checklist

Change the question from "did last night's backup run" to "if the main server died right now, who restores it, from which copy, how long does it take, and what does finance need to see before they accept it". The second question forces answers from people who normally sit at different desks: where the files are, who has the passwords, how the network is set up, and who knows what the report totals should be.

The times in this article are examples to explain the method. They are not Saeree ERP service commitments or industry standards. Each organisation sets its own targets. Technical references were checked on 22 September 2026.

1. A Successful Backup Does Not Mean You Can Restore

There are three levels of checking, and each answers a different question. Most organisations stop at the first.

Even PostgreSQL's own tooling warns that pg_verifybackup checks the backup files but cannot replace starting the database and using it. You still have to do a test restore and check the data [1].

A working login page is not the finish line either. Some user groups may not be able to log in, attachments may not open, a report may depend on another service. Start from the work the organisation cannot do without, then trace backwards to everything that work depends on.

2. RPO (Recovery Point Objective) and RTO (Recovery Time Objective) in Plain Business Terms

RPO (Recovery Point Objective) is how many minutes or hours of data you can afford to lose. RTO (Recovery Time Objective) is how long the system can stay down before it must be usable again. Business and IT agree these two numbers together, and the agreement must say when the clock starts and what "usable again" means in practice.

Example: the system goes down at 14:00. With an RPO of 15 minutes, the restored data must be complete to at least 13:45. With an RTO of four hours, business users must be doing critical work again by 18:00. Finishing the database restore at 15:00 does not count as done if attachments still will not open or users still cannot log in.

Ask process owners exactly what they can live with. If two hours of data are lost, which paper documents do they re-key the goods receipts from? While the system is down, who writes transactions down, and who enters them afterwards? Cutting downtime and cutting data loss cost different money. Management needs to see the options alongside drill results before setting targets.

3. What Saeree ERP Is Made Of, and What You Must Back Up

Before planning, know what the system consists of. Saeree ERP has a simple structure: all the data lives in one place.

The joint StopRansomware Guide from CISA recommends offline, encrypted backup copies and regular restore testing [3]. In your drill, also test that the person responsible can actually retrieve that copy and use it, without depending on a single individual.

4. Pick a Backup Method That Matches Your RPO

A system running on a VM has three backup options. They can be combined, and most organisations should use at least two.

A warning about the database restore script shipped with the system: it drops the existing database and creates a new one before importing. Run it on the test machine only, and check the target database name every time before pressing Enter. If you are also upgrading PostgreSQL, test that as a separate exercise so you know whether a problem came from the restore or from the upgrade. Read more in why Saeree ERP chose PostgreSQL and our ERP security guidance.

5. Drill on a Separate Machine, and Close the Exits Before Starting the Application

Build a new VM on a network isolated from production. Before starting WildFly, disable outgoing email, external integrations and scheduled jobs, because the restored database carries production settings with it, including user email addresses and the endpoints it was connected to.

An example of checking that a dump file really restores. Run it on the test machine, and adjust the database and user names to your system.

# Test machine only
createdb -U erp_user erp_test
psql -U erp_user -d erp_test -f ExpDat.dmp

# Recovered data point = timestamp of the newest record in the database
psql -U erp_user -d erp_test -c "select max(created) from c_invoice;"

Agree the scenario before you start, for example "the main server is dead but the backup files are intact" or "the primary administrator cannot be reached". Each scenario tests a different weak point. If IT prepared the machine in advance, say so in the report, so the measured time is not mistaken for a real incident-to-service time.

Start with a handful of critical tasks: open the remaining budget balance, find a purchase order, open its attachment, and post one goods receipt. The people who do that work every day should run the test, not IT on their behalf.

6. The Business Signs Off, Not IT

Prepare reference records before the drill day. "The data looks complete" cannot be repeated, and it usually misses the transactions entered just before the outage.

Write down the time at every step: scenario starts, responsible person reached, backup files retrieved, database restored, application up, business confirms it works. Once you see the times step by step you know where the bottleneck is. Often it is finding a person or waiting for a password, not the speed of the hardware.

7. A One-Page Report Management Can Act On

Backup file checks can run often and automatically. A full restore drill belongs after major changes, such as a PostgreSQL upgrade or a move to a new VM, and at least once a year. Set the frequency from how critical the work is and the budget you have, not from someone else's number.

8. What We Recommend to Saeree ERP Customers

Because every module lives in one database and the application is a WAR that can simply be reinstalled, recovering Saeree ERP comes down to one main job: get the database back, complete and at the right point in time. Our recommendations:

• Two layers of backup: a VM-level backup to bring the whole machine back fast, and a daily database dump kept off the machine for a clear recovery point that can also be moved to new hardware.
• If you need an RPO in minutes, add PITR and plan the storage for WAL.
• Keep the production WAR version, the WildFly configuration and customised reports next to the backups, so nobody has to hunt for them during an incident.
• Drill the restore onto a new VM on the Proxmox or VMware you already run, at least once a year and after every major upgrade.
• Use the list of modules your organisation actually uses to decide which departments must sign off.

Time targets, password custody and who performs the restore differ by customer agreement. Our team can build the runbook together with your system administrators. If AI helps summarise the drill report, send only the information you are allowed to share and have the responsible person check it again. AI output is not proof that the restore worked.

Conclusion

Start with one scenario and one set of critical tasks. Check the backup, restore onto a separate machine, time it until the business says it works, then fix what failed before the next round. What the organisation gets is an evidence-backed answer to three questions: in a real incident, how many hours of data would be lost, how many hours would work stop, and who has to do what.

Confidence that you can recover comes from the day you actually did it, not from a message that says the backup succeeded.

— Paitoon Butri

References

Checked 22 September 2026. PostgreSQL 18 documentation is used as the example; use the manual matching your installed version. The checklist and example figures are the author's recommendations.

1. PostgreSQL: pg_verifybackup
2. PostgreSQL: Continuous Archiving and Point-in-Time Recovery
3. CISA, FBI, NSA and MS-ISAC: StopRansomware Guide (2023)