# ERP Database Backup Checklist

> Source: https://netray.co/tools/erp-database-backup-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Check your ERP backup strategy for coverage, retention, encryption and, most important, tested restores.

## Category

erp-operations

## Audience

- ERP administrator
- IT manager
- ERP DBA

## Tool

**Kind:** checklist

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

**Groups:**

#### Scope and schedule

**Items:**

**Text:** List every database the ERP needs: main, reporting, document store, integration and licensing

**Critical:** true

**Text:** Include non-database data: attachments, custom reports, config files, integration scripts and certificates

**Critical:** true

**Text:** Set full, differential and log backup frequency from the recovery point objective (RPO)

**Critical:** true

Use the FULL recovery model if you need point in time recovery, and schedule log backups

Back up system databases (master, msdb) and server level objects such as logins and jobs

Stagger backups away from period close, MRP and batch posting

Record who owns the backup jobs and who is the backup deputy

#### Storage and protection

**Items:**

**Text:** Keep at least three copies on two media types with one copy offsite (3-2-1 rule)

**Critical:** true

**Text:** Keep one copy immutable or offline so ransomware cannot encrypt it

**Critical:** true

**Text:** Encrypt backups at rest and in transit and store the keys separately

**Critical:** true

Use backup checksums and verify after write (WITH CHECKSUM on SQL Server)

Restrict who can delete or alter backups and log all access

Keep backup storage off the same server and the same domain admin credentials as production

Confirm backup storage has headroom for growth over the retention period

#### Retention and compliance

**Items:**

Set retention from legal, tax and customer requirements, not only disk space

**Text:** Check contract and regulatory rules on where data may be stored (for example export-controlled or personal data)

**Critical:** true

Define how deletion requests are handled for data held in old backups

Keep a monthly and yearly archive for audits where needed

Retain ERP installation media, license keys and version patch levels with the backups

#### Restore testing and monitoring

**Items:**

**Text:** Restore the full backup chain to a separate server at least quarterly and run the ERP against it

**Critical:** true

**Text:** Time the restore and compare it with the recovery time objective (RTO)

**Critical:** true

Run 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 transactions

**Text:** Alert on failed, missed or unusually small backups, not only on job errors

**Critical:** true

Document the step by step restore runbook, including credentials location and order of services

Rehearse a point in time restore after a bad data load

Review the whole plan after every upgrade, migration or infrastructure change

## Content

**Intro:** Most ERP outages that become disasters are not caused by the failure itself but by a backup that was missing, corrupted, encrypted by malware or never tested. This checklist covers the full chain from scope to restore proof.

**Sections:**

#### How to use the checklist

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### How often should I test an ERP restore?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

erp database backup checklist, erp backup strategy, erp disaster recovery checklist, sql server backup best practices, erp restore test checklist, backup retention policy erp, 3-2-1 backup erp, erp backup audit

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json