ERP Database Backup Checklist (Free, PDF/Excel)

0%

0 of 27 items complete

10 critical items still open - these are the highest-risk gaps.

Download checklist:

Scope and schedule

List every database the ERP needs: main, reporting, document store, integration and licensingCRITICALInclude non-database data: attachments, custom reports, config files, integration scripts and certificatesCRITICALSet full, differential and log backup frequency from the recovery point objective (RPO)CRITICALUse the FULL recovery model if you need point in time recovery, and schedule log backupsBack up system databases (master, msdb) and server level objects such as logins and jobsStagger backups away from period close, MRP and batch postingRecord who owns the backup jobs and who is the backup deputy

Storage and protection

Keep at least three copies on two media types with one copy offsite (3-2-1 rule)CRITICALKeep one copy immutable or offline so ransomware cannot encrypt itCRITICALEncrypt backups at rest and in transit and store the keys separatelyCRITICALUse backup checksums and verify after write (WITH CHECKSUM on SQL Server)Restrict who can delete or alter backups and log all accessKeep backup storage off the same server and the same domain admin credentials as productionConfirm backup storage has headroom for growth over the retention period

Retention and compliance

Set retention from legal, tax and customer requirements, not only disk spaceCheck contract and regulatory rules on where data may be stored (for example export-controlled or personal data)CRITICALDefine how deletion requests are handled for data held in old backupsKeep a monthly and yearly archive for audits where neededRetain ERP installation media, license keys and version patch levels with the backups

Restore testing and monitoring

Restore the full backup chain to a separate server at least quarterly and run the ERP against itCRITICALTime the restore and compare it with the recovery time objective (RTO)CRITICALRun integrity checks (RESTORE VERIFYONLY is not enough; run DBCC CHECKDB on a restored copy)Have a business user sign off the restored data for a sample of transactionsAlert on failed, missed or unusually small backups, not only on job errorsCRITICALDocument the step by step restore runbook, including credentials location and order of servicesRehearse a point in time restore after a bad data loadReview the whole plan after every upgrade, migration or infrastructure change

A backup that has never been restored is an assumption, not a backup. Treat every critical item as pass or fail.

Recovery readiness review

Want a second opinion on your ERP backup and recovery design? Optional, no obligation.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Walk through each group with the person who owns the backups and the person who would restore them; they are often different people. Tick items you can prove, not items you believe. Export the result to PDF or Excel for your audit file. Anything you cannot tick becomes a dated action with an owner. Repeat after any significant change, and at least twice a year.

RPO, RTO and what they decide

Recovery point objective is how much data you can afford to lose, for example 15 minutes of transactions. It sets how often you take log backups. Recovery time objective is how long the business can be without the ERP, and it sets the restore method and hardware. A plant that ships daily may accept an hour of lost data; one with real time shop floor reporting may not. Write both numbers down and test against them, because backup frequency alone does not guarantee either.

RPO drives backup frequency
RTO drives restore design and bandwidth
Both must be agreed with the business, not set by IT alone

Beyond the database

An ERP is more than its main database. Attachments, custom reports, integration middleware, EDI maps, license files, certificates and configuration all matter during recovery. Cloud and hosted ERPs shift some of this to the vendor, but you still need to know their retention, restore request process and your own exports. Check the contract rather than assuming. For on-premises air-gapped sites, plan for offline media and a documented transport process.

Common mistakes

Keeping backups on the same SAN or hypervisor as production means one failure takes both. Backup jobs that succeed while backing up an empty or wrong database are common after migrations. Encryption keys stored only on the encrypted server make recovery impossible. Using the same admin credentials for backup storage as for production lets ransomware delete backups. Never testing is the most frequent and most costly error.

Frequently Asked Questions

How often should I test an ERP restore?

At least quarterly for the main database, plus after major changes, with a full restore to a separate server and a business check of the data. Annual tests are too rare to catch silent corruption or missing components.

What is the 3-2-1 backup rule?

Keep three copies of your data, on two different types of media, with one copy offsite. Many teams now add an immutable or offline copy to survive ransomware, sometimes called 3-2-1-1.

Do I need log backups for my ERP database?

If the database uses the FULL recovery model and you need point in time recovery, yes. Without log backups the log grows without bound. If you accept restoring to the last full backup, SIMPLE recovery may be fine, but decide deliberately.

Does a cloud ERP still need my own backups?

Check what the vendor covers. Many provide platform recovery but not recovery from your own mistakes such as a bad import. Regular exports of key data and configuration give you an independent copy.

If you want help designing an on-premises recovery plan for ERP and the AI or reporting layers around it, we can work through it with your team.

Talk to an Expert Explore More Free Tools

Related Tools

ERP Operations

More ERP Operations tools

See all

ERP Database Backup Checklist