Ecommerce disaster recovery: RPO, RTO and restore testing

A backup is not yet a disaster recovery plan

An ecommerce service is more than a database. A customer journey depends on the storefront, code, configuration, catalogue, orders, customer records, inventory, media, DNS, identity, secrets and integrations. A data copy can be readable and still be insufficient to reopen the store. Disaster recovery covers the complete path: detect the incident, choose a recoverable point, rebuild the environment, restore components in the right order, reconnect them and prove that the business workflow actually works.

This changes the operational question. Instead of asking only whether a backup exists, teams need to know which losses are acceptable, how long an interruption may last and what evidence demonstrates recovery under realistic conditions. The result should be a repeatable process with owners, dependencies and exit criteria, not a document that is first opened during an emergency.

Translate risk into RPO and RTO

Two different objectives derived from the business

The Recovery Point Objective, or RPO, is the maximum acceptable window of data loss. The Recovery Time Objective, or RTO, is the maximum acceptable time to restore a component after an interruption. These are targets rather than technical guarantees. They should come from the impact on customers, operations, revenue and company obligations, rather than from a default value advertised by a platform.

Tighter targets generally increase cost and complexity because they demand more frequent copies, ready capacity, automation, observability and well-rehearsed procedures. Assigning RPO and RTO per component is therefore more useful than applying one number to the entire platform. Catalogue data may tolerate different conditions from orders or inventory. Media might be reproducible, while secrets and configuration require a separate custody model. A business owner should understand and approve each trade-off.

Build a dependency inventory

Start with journeys that create business value

Map the critical paths from a user's perspective: open the store, find a product, sign in, place an order, update stock, receive confirmation and manage fulfilment. For every step, identify applications, databases, storage, queues, identity providers, DNS, certificates, secrets, endpoints and external integrations. Record the authoritative source for each dataset and whether a dependency is restored from a copy, recreated from code or reconfigured through a controlled procedure.

The inventory must also cover elements that traditional backups often miss: environment settings, routing rules, templates, permissions, job definitions, webhook mappings and operating guides. Link each component to its owner, RPO, RTO, copy location and validation method. If an integration cannot be exercised outside production, document a controlled substitute and the check that must occur before production traffic resumes.

Keep redundancy, replication and backup distinct

Redundancy, replication and backup solve complementary problems. Redundancy can keep a service available when one resource fails. Replication maintains current copies, but it may also propagate deletion, corruption or a faulty configuration. Backup preserves a recoverable point-in-time state, yet it does not by itself prove that the application can be rebuilt within its target. A sound plan combines these controls according to risk rather than treating them as interchangeable.

Critical copies should be isolated and protected from unnecessary access. Joint ransomware guidance recommends offline, encrypted backups together with regular tests of availability and integrity. Define separate identities, least privilege, retention, versioning and a procedure for recovering credentials. A copy reachable by the same compromised account as the primary environment does not provide the intended isolation.

Make the environment reproducible

Configuration and restoration order matter

Version application code, non-secret configuration and infrastructure definitions. Infrastructure as code reduces manual work and makes the recovered environment easier to compare, but those definitions must remain accessible when primary systems are unavailable. Secrets do not belong in templates: document how they are retrieved or rotated and who is authorised to do so. Retain the artefacts required to deploy a known application version.

Write an explicit sequence. A cautious example is to activate emergency access, rebuild network and identity, restore data and storage, deploy applications, reconnect DNS and integrations, and then reopen traffic progressively. The correct order depends on the architecture. Every step should identify an owner, prerequisites, command or procedure, expected evidence and a stop condition. Include an escalation route when a control fails.

Run an end-to-end restore test

Use an isolated drill, not a file inspection

Start the exercise in an isolated environment using copies selected for a defined recovery point. Measure from incident activation until all checks are complete. Restore without relying on resources that the plan assumes are unavailable. Record every manual intervention, missing permission, external delay and departure from the runbook. Testing should show both that recovered data meets the RPO and that the database and application function within the RTO.

Do not stop when the database starts. Verify authentication, authorisation, catalogue search, prices and availability, order creation, inventory updates, a safely simulated payment path, notifications, queues and webhooks. Check service reconnection, certificate validity, object permissions, logs, metrics and alerts. Compare samples and totals against the expected source, look for corruption and ensure that replaying events or operations does not create duplicate effects.

Measure recovery and close gaps

Compare actual elapsed time with the RTO for each component and compare the newest recovered point with its RPO. Record detection time, time to obtain access, rebuild duration, restore duration, failed controls, manual steps and unavailable dependencies. Separate delays from integrity failures. Every defect needs an owner, priority, corrective action and a scheduled retest.

Data growth, corrupt backups, permission changes and configuration drift can invalidate a plan that succeeded before. Use a risk-based cadence and repeat testing after meaningful architecture changes, migrations, new payment paths or identity changes. There is no universal frequency: the schedule should reflect impact, rate of change and evidence from the previous exercise.

Common mistakes and a practical path

Frequent mistakes include declaring success after downloading a file, keeping copies in the same security domain, omitting DNS and secrets, relying on undocumented knowledge, and timing the restore without validating the application. Testing only the ideal path is also risky. A drill should include a credential rotation, an unavailable dependency and an explicit decision about the recovery point.

Begin with the dependency inventory and business priorities. Assign RPO and RTO, isolate copies, make configuration and access reproducible, and then rehearse the complete path in a separate environment. If you need to design the architecture or consolidate fragmented procedures, explore our ecommerce systems and development services. A plan is only as credible as its latest observable test; to assess dependencies, timings and controls for your store, contact AE Digital Agency and build a verifiable roadmap.