# How to Test ERP Backup and Disaster Recovery > Source: https://netray.co/erp-help/itm-erp-backup-and-disaster-recovery-test-plan > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items. ## Kind how-to ## System it-leadership ## Erp Any ERP (on-prem and hosted) ## Module Infrastructure / Backup and Disaster Recovery ## Query how to test ERP disaster recovery and backup restore ## Alternate Queries - ERP disaster recovery test plan template - how often should we test ERP backups - ERP RTO RPO how to define - restore ERP database to test environment steps ## Applies To On-prem and self-hosted ERPs on SQL Server, Oracle or SAP HANA, such as SAP, SyteLine, Infor LN, Dynamics, Epicor, JD Edwards. SaaS ERPs need a different test focused on export and vendor evidence. ## Steps ### ERP DR test procedure **Items:** - Agree RPO (how much data you can lose) and RTO (how long you can be down) with finance and operations, per process. Month-end close and shop-floor transactions often differ. - Inventory everything the ERP needs to run: database, application servers, file shares and attachments, report server, integration middleware, scheduled jobs, certificates, license files, DNS and service accounts. - Restore the latest full backup plus logs to an isolated network and a different host name. Time the restore and note the point in time reached. - Run integrity checks on the restored copy. SQL Server: DBCC CHECKDB on the restore. Oracle: validate with RMAN. SAP HANA: confirm the recovery reached the target timestamp. - Bring up the application tier against the restored database, repoint connection strings and integrations to test endpoints so nothing posts to production partners or banks. - Execute a scripted smoke test: log in as a real role, open a sales order, post a receipt, run a trial balance, print a document, run one integration message. - Compare record counts and the last posted transaction time against production to confirm the actual RPO achieved. - Write the timeline, gaps and fixes in a short report and schedule the retest for every failed item. ## Sections ### RPO and RTO in plain terms **Body:** RPO is the age of the newest data you can restore. If you take nightly full backups only, your RPO is up to 24 hours, which means a full day of orders, receipts and postings would need re-entry. Transaction log backups every 15 minutes bring RPO down to roughly that interval. RTO is how long the business can tolerate the ERP being unavailable before real damage occurs, such as missed shipments or stopped production lines. Do not set these in IT alone. Ask the plant manager what happens if the system is down for four hours versus a day, and ask finance what happens during close. The answer often shows that different tiers need different targets: the shop floor and shipping module may need faster recovery than reporting or HR. Then check the architecture against the target. A 15-minute RPO needs log backups or replication. A 1-hour RTO is not credible if the restore of a 2 TB database alone takes 3 hours. The test exists to expose that gap with a stopwatch rather than during an incident. ### What the backup must cover beyond the database **Body:** Teams commonly protect the database and forget everything the ERP needs around it. Customisations and custom reports stored on application servers, document attachments on a file share, the encryption keys or certificates for integrations, license servers, SSRS or report definitions, and scheduled job definitions all have to come back for the system to be usable. Integrations are the second blind spot. EDI connections, bank interfaces, MES and shop-floor links, e-invoicing portals and middleware flows each carry credentials and endpoints. Document how each is brought up in DR and, importantly, how it is kept from sending test data to real partners during an exercise. Keep one copy of the backups and the runbook outside the failure domain. If ransomware encrypts the domain, backup storage reachable with the same credentials is encrypted too. An immutable or offline copy and a printed or separately stored runbook have saved many recoveries. **Code:** -- SQL Server: restore a full backup and verify (test host only) RESTORE VERIFYONLY FROM DISK = N'D:\\Backups\\ERP_Full.bak'; RESTORE DATABASE ERP_DRTEST FROM DISK = N'D:\\Backups\\ERP_Full.bak' WITH MOVE 'ERP_Data' TO N'E:\\DRTest\\ERP_Data.mdf', MOVE 'ERP_Log' TO N'F:\\DRTest\\ERP_Log.ldf', STATS = 10; DBCC CHECKDB (ERP_DRTEST) WITH NO_INFOMSGS; ### Running the exercise and measuring honestly **Body:** Start each test with a written scenario: for example, primary database host lost, or storage corrupted at 02:10. Assign roles, start a log with timestamps, and have a scribe record every command and decision. The clock covers detection, decision to fail over, restore, application bring-up and business validation, not just the database restore. Include business users in the smoke test. A DBA saying the database is online is not recovery; a buyer posting a purchase order and a stores clerk issuing material is. Keep the test script short and the same each time so results are comparable between tests. Measure the gap between target and actual for both RTO and RPO and record it, even when it is embarrassing. A documented gap with an owner and a date is a mature finding; a clean report that nobody believes is not. ### Frequency and what to retest **Body:** Run a full restore test at least annually, and after major changes such as an ERP upgrade, a move to new storage or virtualisation, or a change in backup tooling. Between full tests, schedule a smaller automated restore of the latest backup monthly, followed by an integrity check, so silent backup corruption is found within weeks. Test different failure types over time: single database loss, whole site loss, ransomware recovery from immutable copies, and loss of an individual integration. Rotating scenarios finds different weaknesses. Keep a dated evidence pack: the scenario, the timeline, integrity check output, smoke test results and the action list. Customers in aerospace and defense supply chains, and auditors, increasingly ask for this. ## Pitfalls - Counting a successful backup job in the monitoring console as proof of recoverability without ever restoring. - Restoring only the database and forgetting attachments, custom code, certificates and license servers. - Letting the restored test system connect to live bank, EDI or supplier endpoints and send duplicate transactions. - Testing only the technical restore and skipping business validation by real users. - Backups stored on the same storage array or reachable with the same admin credentials as production. - Never retesting after fixes, so action items stay open indefinitely. ## Ai Angle An assistant like ERPray, connected read-only to the restored copy, can run the post-restore comparison questions for you, such as latest posted transaction time, open order counts and trial balance totals against production, and show the queries it used. It does not perform the restore or failover; those remain with your DBA and infrastructure team and your runbook. ## Faq ### How often should we test an ERP restore? **Answer:** Do a full restore and business smoke test at least once a year and after major infrastructure or ERP version changes. Add a monthly automated restore and integrity check of the latest backup so corruption is found early. Critical manufacturers often test twice a year. ### What is a reasonable RPO and RTO for an ERP? **Answer:** It depends on the business, not on IT preference. Many manufacturers land near 15 minutes to 1 hour RPO and 4 to 8 hours RTO for core transactions, with looser targets for reporting. Set them with operations and finance, then prove the architecture can meet them. ### Is a backup enough for disaster recovery? **Answer:** No. A backup is one input. DR also needs infrastructure to restore onto, network and DNS changes, integration bring-up, access for staff, and a rehearsed runbook. Without those, restoring may take days even with perfect backups. ### How do we test DR for a SaaS ERP? **Answer:** You cannot restore the vendor platform, so test your side: obtain the vendor's recovery targets and recent test evidence, confirm you can export data on a schedule, and rehearse operating the business on exports and manual procedures for a day if the service is unavailable. ## Search terms ERP disaster recovery test, ERP backup restore test, ERP RTO RPO, ERP DR plan template, test ERP database restore, ERP business continuity plan, SQL Server restore ERP test, ransomware recovery ERP, ERP failover test, DR evidence for audit --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json