Disaster Recovery
Disaster recovery is the planned restoration of IT systems and data after a serious failure – such as a server defect, ransomware, fire or data-centre outage. The goal is to make a system like the ERP operational again within a predefined time and with the least possible data loss.
Disaster recovery (DR for short) refers to the entirety of all procedures, plans and resources with which a company returns its IT systems and data to an operational state after a serious failure. Such a "disaster" is not the everyday glitch, but an event that paralyses regular operations entirely or in large part: a hardware defect on the server, an encryption attack via ransomware, a fire or water damage in the data centre, a serious operating error or the outage of a cloud site. Disaster recovery answers the question of how quickly and with what data state the systems run again afterwards.
In the ERP context, disaster recovery is especially critical because the ERP system is a company’s operational nerve centre: orders, inventory, invoices, accounting and customer data all reside there. If it fails, the entire business quickly grinds to a halt – nothing can be picked, invoiced or posted. A resilient DR strategy therefore defines in advance which systems are restored with which priority, how long that may take and how much data loss is bearable in the worst case.
At a glance
- Disaster recovery = planned restoration of IT and data after a serious failure
- Two metrics steer everything: RPO (maximum tolerable data loss) and RTO (maximum tolerable downtime)
- DR is more than a backup: it comprises plan, target environment, restart and regular testing
- Decisive for the ERP, because orders, inventory and accounting all converge there
- With SaaS/cloud ERP the provider supplies DR – responsibility and deadlines are stated in the SLA
What belongs to a disaster recovery strategy?
Disaster recovery is not a single tool but a coordinated bundle of technology, processes and responsibilities. Core components are a documented recovery plan (disaster recovery plan), a sufficiently distant second copy of the data, a target or fallback environment in which the systems can restart, as well as clear roles: who decides in an emergency, who restores, who informs customers and authorities. Without this organisational side, even the best technology remains ineffective in an emergency.
A good DR strategy also ranks the systems by priority. Not everything has to be back equally quickly: the ERP and order processing are usually at the very top, while an internal wiki, for example, can tolerate longer outages. This prioritisation emerges from a business impact analysis that estimates for each process what damage arises per hour of standstill.
RPO and RTO: the two central metrics
Every DR plan revolves around two target values. The Recovery Point Objective (RPO) describes how much data loss is at most acceptable – that is, the period between the last secured data copy and the failure. An RPO of one hour means: in the worst case the data of the last hour is lost, so backups must be taken at least hourly.
The Recovery Time Objective (RTO) defines how long the restoration may take at most until a system is productive again. An RTO of four hours means the ERP must be usable again no later than four hours after the failure. Both values directly determine the cost: very short RPO and RTO require more elaborate technology such as real-time mirroring, while more generous targets can make do with simple backups.
How disaster recovery works in practice
Technically, disaster recovery relies on data and system states being kept redundantly at a second, spatially separate location. This ranges from regular, offsite backups through continuous replication to a fully second data centre that steps in during an emergency. The spatial separation is decisive: if the second copy sits in the same server room, it is no help in the event of fire or theft.
A proven basic principle is the 3-2-1 rule: three copies of the data, on two different media types, one of them at an external location. Against ransomware, an immutable, network-disconnected copy (immutable or offline backup) is often added so that attackers cannot also encrypt the backup.
The actual emergency then follows the restart plan: the target system is provisioned, the most recent intact data state is loaded, the application is started and checked before users are admitted again. Because much reads more simply in theory than under the stress of a real emergency, every serious DR strategy includes regular testing – a simulated outage in which the restoration is actually run through and the time is measured.
Disaster recovery vs. backup vs. high availability
Disaster recovery is often confused with neighbouring terms that, however, achieve different things. The clean distinctions help to size your own safeguarding correctly.
Backup is only one building block
A backup is pure data protection – a copy from which files or databases can be retrieved. Disaster recovery, by contrast, covers the complete path back into operation: plan, fallback environment, restart and test. A backup without a DR plan answers the question "is the data there?" but not "how does the ERP run again in four hours?". Backups are necessary, but on their own are not disaster recovery.
High availability prevents, DR repairs
High availability aims to prevent failures from becoming noticeable at all – for instance through redundant servers that take over without interruption in the event of a defect. It is often assured via an availability SLA. Disaster recovery comes in one step later: it applies when a failure has occurred anyway and entire systems or sites have to be restored. The two complement each other – HA against the everyday defect, DR against the major catastrophe.
Disaster recovery in the ERP system
For the ERP, disaster recovery has special significance because inventory management, sales and finance all converge at one point here. A longer outage means not only stalled processes but potentially also inconsistent data: orders that came in via the shop during the outage, stock postings from the warehouse or incoming payments must be cleanly reconciled after the restoration. That is why with ERP DR not only the data state of the ERP itself matters, but also the synchronicity with connected systems via the respective interfaces.
How DR is implemented in concrete terms depends heavily on the operating model. With a cloud or SaaS ERP, the provider operates the infrastructure and supplies disaster recovery as part of the service – including geo-redundant data centres, automatic backups and assured restart times. The customer then mainly has to check which RPO and RTO values are stated in the contract and how to additionally secure exported data. With an on-premise ERP, full responsibility lies with the company itself: backup, fallback site, plan and tests must be organised independently or via a service provider.
DACH specifics: GDPR, retention and responsibility
In the German-speaking region, disaster recovery is not only a technical but also a legal question. The GDPR explicitly requires in Article 32 the ability "to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident" – disaster recovery is thus effectively mandatory, not optional, for companies handling personal data. In the event of a data loss, a reporting obligation to the supervisory authority may also apply.
On top of this come tax retention obligations: accounting-relevant data from the ERP must be kept audit-proof and recoverable for many years – an aspect that closely intertwines DR and archiving. Anyone outsourcing parts of operations to a cloud provider remains responsible under data protection law and should check the server location, the certification (such as ISO 27001) and the contractually assured recovery deadlines. A documented DR strategy is thus at the same time part of the duties of accountability and due care.
Example
Example: ransomware hits an online retailer
A mid-sized e-commerce retailer with around 400 orders a day runs its ERP on its own server. On a Monday morning all systems are encrypted – a ransomware attack has also captured the regular backup disk on the same network. Because the company additionally runs a daily, network-disconnected offline backup (RPO 24 hours) and holds a documented restart plan, the DR strategy takes effect.
The IT team loads the intact data state from the previous day onto a provisioned replacement server and restarts the ERP after just under five hours – within the previously defined RTO. The orders from the day of the attack are then re-imported from the shop and marketplace via the interfaces. Without the offsite, immutable backup, all order and inventory data would have been lost and operations would have stood still for days.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Disaster Recovery in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.