Disaster Recovery: Restoring Your Shop After an Incident

A DR plan without measurable targets stays non-binding. Two metrics give it structure: RTO (Recovery Time Objective) describes how quickly the shop must be available again after an outage. RPO (Recovery Point Objective) describes how much data loss is acceptable -- how old the most recent available data state may be at most. An RPO of one hour means that, in the worst case, the data of the last 60 minutes is lost. An RTO of four hours means the shop is back online at most four hours after the outage.

Both values have direct business meaning. The RTO determines the maximum downtime and thus the revenue loss -- the average cost of unplanned outages is put at roughly 5,600 US dollars per minute (Gartner) in current studies, though this value varies strongly by industry and company size. The RPO determines how many orders, customer accounts or content changes must be re-entered manually in an emergency. The lower both values, the higher the technical and financial effort -- the art lies in an economically sensible balance.

The right tier depends on the business model. A shop with few orders per day can live with an RPO of 24 hours, while a high-revenue shop with hundreds of transactions per hour needs an RPO in the range of minutes. This classification is the foundation of every DR plan and should be set together with the technical reality of the hosting environment. It determines how much technical effort is required and which residual risk is consciously accepted.

A DR plan must cover different types of outage, because each requires a different restore path. Ransomware encrypts data and often targets the backups in parallel -- the average downtime after a ransomware attack is 24.6 days (Statista). Hardware failures on the server, faulty updates, databases deleted by operator error, hosting provider outages and systems compromised after a breach are also realistic scenarios.

For the compromise scenario, the DR plan and the security incident interlock. How cleanup and a clean restart after a breach work is described in detail in the emergency plan for a hacked website. The key point: recovery must come from a state before the compromise, since later backups may already contain malicious code.

The restore test is what distinguishes a DR plan from a backup configuration. In the test, recovery is actually performed in an isolated environment -- ideally in a dedicated staging environment that mirrors the production system. The test reveals what was overlooked in theory: missing permissions, forgotten configuration files, incompatible PHP or database versions, expired certificates or incomplete backups.

A complete restore test also measures the actual RTO: how long does recovery really take? If the measured value exceeds the defined target, either the process must be optimized or the target adjusted realistically. This measurement turns an assumption into a reliable commitment. Recovery speed is improving measurably: 53 percent (Varonis, 2025) of organizations recovered from a ransomware incident within a week in 2025, up from 35 percent (Varonis, 2025) the previous year -- progress that is hard to achieve without tested plans.

A low RTO comes from automation and preparation. The more steps are documented, scripted or kept on standby in advance, the shorter the downtime. A prepared standby system (warm or hot standby) can lower the RTO from hours to minutes, but is more elaborate and costly. For many shops, a well-documented and practiced manual restore process with a clear order is the pragmatic middle ground.

Professional monitoring reduces the detection time of an outage to minutes and is therefore the prerequisite for a short RTO -- because downtime begins with the outage, not with its discovery. The earlier a problem is detected, the earlier recovery starts.

For the RTO, it is worth looking at the individual recovery phases in detail. The measured total time typically consists of detection, decision, data transfer, rebuild and verification. In many cases the actual restore is not the bottleneck but the upstream clarification -- who decides which backup is used, and who has access to the necessary systems. Clarifying these organizational steps in advance and including them in the plan often gains more time in an emergency than any technical optimization. A realistic DR plan therefore calculates the RTO as the sum of all phases, not just the pure data copy time.

The restart location must also be considered. If only one component fails, recovery on the existing infrastructure is enough. But if the entire location or hosting provider fails, the shop must be brought back up in an alternative environment -- with all dependencies from DNS to payment integration. This case should be described separately in the DR plan and rehearsed at least once, as it involves considerably more steps than a simple restore in the same place. The location-independent offsite copy is the technical prerequisite here, the documented restart procedure the organizational one.

Disaster recovery is not a one-time setup but an ongoing process. Backup chains must be monitored, restore tests run regularly and the plan adapted to every major change of the shop. In a maintenance contract, this process becomes a predictable routine: defined RTO and RPO targets, monitored backups, documented recovery procedures and restore tests at fixed intervals.

The benefit lies in reliability. Instead of improvising in an emergency, a well-practiced team follows a rehearsed procedure. The investment in a DR plan is a fraction of the potential damage -- given average outage costs of around 356,000 US dollars per day (Varonis, 2025) for larger incidents, preparation pays off quickly. How a maintenance contract is structured in detail is described in the article on what a maintenance contract should include.