ERP backup and disaster recovery: the essential guide

Your ERP holds your invoices, your stock, your accounts and your customer history. Losing a day of data means, at best, re-entering a day of work. At worst, it means you can't invoice, ship or close the books while you rebuild.

Yet the goal isn't to have backups: it's to be able to restore, quickly and cleanly. This guide covers the essential ideas, the mistakes to avoid and a checklist to take stock of where you stand.

Backup, replication, disaster recovery: three different things

These three words are often mixed up. They don't protect against the same risks.

• A backup is a copy of your data at a point in time, kept for a set period. It lets you go back after a deletion, a corruption or an attack.
• Replication keeps a second copy continuously up to date on another server. It protects against a machine failing, but it copies mistakes too: a table deleted by accident is instantly deleted on the replica. Replication doesn't replace backups.
• A disaster recovery plan describes how to restart the service after a major incident: who decides, in what order systems come back, from which copies, and how you check the data is sound.

A solid setup combines all three: replication for failures, backups to go back in time, and the plan to know what to do on the day.

RPO and RTO: set your objectives before the technology

Two measures shape any recovery strategy:

• RPO (Recovery Point Objective) is the most data you accept to lose, expressed as time. With one backup a night and nothing else, an incident late in the day can cost up to a full day of entries.
• RTO (Recovery Time Objective) is the longest interruption you accept before the service is back.

These objectives aren't decided by IT alone, but with the business. Ask concrete questions: how many hours of entries can we redo? How long can we invoice, ship or pay without the ERP? The answer often depends on the period: an outage in the middle of month-end closing doesn't cost the same as an ordinary Tuesday.

The more ambitious the objectives, the more the setup costs. Setting them first avoids overpaying for protection you don't need, or finding out too late that it wasn't enough.

The 3-2-1 rule, applied to an ERP

The 3-2-1 rule remains the foundation of a backup strategy:

• 3 copies of your data: production and two backups.
• 2 different media or storage systems, so a single failure doesn't take them out together.
• 1 copy off-site, safe from an incident at the main location.

Against ransomware, it's common to add an isolated or immutable copy that attackers can neither encrypt nor erase, even with stolen credentials.

For an ERP, one more precaution: the backup must be consistent. Copying the files of a database while it's being written can produce an unusable backup. Use the database's own tools, or snapshots taken at the right moment.

What to back up, and what gets forgotten

The database isn't enough. To restart a complete ERP, you also need:

• attachments and documents: scanned invoices, delivery notes, files stored outside the database;
• custom developments and add-on modules, in the exact version running in production;
• configuration: settings, users and permissions, scheduled jobs, print templates;
• integrations: connectors, API keys, EDI mappings, certificates and licenses.

A database restored without its configuration or integrations gives you an ERP that starts but doesn't work.

A recovery plan that works on the day

A useful recovery plan is written down, known and tested.

Written down. For each scenario (server failure, data corruption, ransomware, human error, loss of a site), it states who decides, the steps, the restart order (database, application, then integrations), the integrity checks and how users are kept informed.

Tested. Only a real restore proves a backup works. Regular tests, every quarter for example, also measure your real RTO, which is often longer than expected.

Built for ransomware. Keep isolated copies, protected by credentials separate from production, and kept long enough to go back to a date before the infection, which is often discovered late.

The most common mistakes

• Keeping backups in the same place as production, on the same server or with the same access.
• Never testing a restore, and finding out on the day of the incident that a backup is incomplete.
• Backing up only the database, without the files, the configuration or the integrations.
• Treating replication as a backup.
• Not monitoring backup jobs: a silent failure can go on for weeks.
• A retention period too short to go back before a corruption that was noticed late.

What we do at BigBang Cloud

At BigBang Cloud, business continuity is part of the service, not an option:

• Automated backup plans, replication and a managed disaster recovery plan are included for every environment.
• 24/7 monitoring of your environment, day and night.
• Multi-layer security: ZTNA, WAF, VPN, network segmentation and SSL encryption.
• Your data belongs to you: reversibility is full and contractual, and you can get a complete, exportable backup of your database at any time.

Every project starts with an audit of your ERP, its customizations and the applications connected to it: the right time to talk about your recovery objectives.

Checklist

Take stock in five minutes:

1. Are your RPO and RTO objectives agreed with the business?
2. Do you have at least one off-site copy and one isolated copy?
3. Do your backups cover the database, the files, the configuration and the integrations?
4. When did you last restore a backup?
5. Is your recovery plan written down, and does the team know where to find it?
6. Is someone alerted when a backup fails?

If any of these answers gives you pause, let's talk.