Website Disaster Recovery: Defining Backups, RTO, RPO and Restore Testing Before an Incident

Most organisations can answer the first disaster-recovery question confidently: “Yes, our website is backed up.” Far fewer can answer the questions that follow. What exactly is included? How long would restoration take? How much recent data could be lost? Who can authorise a failover? Are the backups isolated from the production credentials? When was the complete service last restored into a clean environment and tested?

A backup is a copy. Disaster recovery is the coordinated ability to return a service to an acceptable operating state after disruption. That difference becomes critical when the website contains orders, enquiries, accounts, memberships, payments, product availability, integrations or time-sensitive content.

The Australian Signals Directorate’s Essential Eight maturity model does not stop at making backups. It calls for data, applications and settings to be backed up in line with business criticality, synchronised to a common point in time, retained securely and resiliently, and restored as part of disaster-recovery exercises. That is a much stronger standard than seeing a green “backup completed” notification.

Backups, resilience, business continuity and disaster recovery are different

These terms are often used interchangeably, which creates gaps in responsibility.

Backup is a recoverable copy of data, code, media, configuration or another asset.
Resilience is the ability of the live service to withstand or automatically recover from a failure, such as through redundant infrastructure.
Disaster recovery is the plan and capability for restoring the service after a serious disruption.
Business continuity is the wider ability of the organisation to continue critical operations, including manual alternatives, communications, suppliers and staff.

High availability does not remove the need for backups. Replication can quickly reproduce corruption, malicious changes or accidental deletion across environments. Backups do not automatically create high availability either. A daily copy may be sound while the service remains offline for days because replacement infrastructure, credentials, documentation or specialist availability were never planned.

The recovery design should match business impact. A brochure website with no transactions may tolerate a longer outage and a modest recovery point. A store processing orders continuously, or a portal used to deliver essential services, may need much tighter objectives and more sophisticated architecture.

Define RTO and RPO in business language

Two measures anchor a useful recovery plan:

Recovery Time Objective (RTO): the maximum acceptable delay between interruption and restoration of the service.
Recovery Point Objective (RPO): the maximum acceptable period of data that could be lost, measured backwards from the incident.

Those definitions align with AWS disaster-recovery guidance, which also makes clear that the organisation defines the objectives. They are not technical numbers a hosting provider should choose in isolation.

If an ecommerce business sets a four-hour RTO and a one-hour RPO, it is saying that the service should be recoverable within four hours and that losing up to one hour of recent data may be tolerable. That immediately creates operational questions. Can missing orders be reconstructed from the payment gateway? Will stock be reconciled? Who contacts affected customers? Are CRM and warehouse events recoverable? Which clock starts the RTO: the first failure, automated detection or human declaration?

Aggressive objectives generally require more infrastructure, automation, monitoring and rehearsal. AWS notes that lower RTO and RPO targets increase cost and operational complexity in its disaster-recovery architecture guidance. The right target is not “zero” by default. It is the point where the cost of improved recovery is justified by the impact of downtime and data loss.

A website is a system of recoverable dependencies

Restoring the database and public files may not restore the service. A complete inventory commonly includes:

application source code and build artefacts
database data, schemas and users
uploaded media and generated documents
environment configuration and feature flags
encrypted secrets, API credentials and certificates
DNS, content delivery network and web application firewall settings
infrastructure configuration
search indexes and cache configuration
scheduled jobs and queues
content management roles and identity-provider settings
third-party plugins, packages and licences
analytics, consent and tag configurations
integrations with payment, CRM, ERP, PIM, WMS, email and other services
deployment pipelines, repositories and access permissions
operational runbooks and supplier contacts.

Some components should be rebuilt from version-controlled configuration rather than restored from an opaque server image. Others require point-in-time data restoration. The plan must state which is which, how versions are matched and how a common point in time is achieved.

This synchronisation issue is easy to underestimate. Restoring a database from 10:00 am and order files from 10:30 am can produce records that refer to transactions the database does not know about. The Essential Eight specifically calls for backups of data, applications and settings to be synchronised so they can be restored to a common point in time.

Model the incidents the plan must handle

“The server is down” is only one recovery scenario. The plan should consider failure modes with different containment and restoration needs.

Infrastructure or regional outage

The application may need to be brought up in replacement infrastructure or another location. DNS changes, certificates, capacity, database replication and third-party allowlists can determine the real recovery time.

Faulty deployment or configuration

A release can cause errors without destroying data. Fast rollback to the last known-good application version may be safer than full restoration, provided database changes are compatible.

Data corruption or accidental deletion

The infrastructure can remain healthy while records or content become unusable. Point-in-time recovery, audit history and reconciliation matter more than a new server.

Compromise or ransomware

Restoring quickly from an untrusted backup can reintroduce the attacker. Recovery must follow containment, forensic and credential-reset decisions. CISA recommends maintaining offline, encrypted backups and regularly testing their availability and integrity in a disaster scenario in its StopRansomware guidance.

Third-party dependency failure

The website may be available while checkout, forms, search, CRM submission or identity stops working. The plan needs graceful failure, queued events, reconciliation and a customer communication path—not necessarily a full website restore.

Domain or account takeover

Control of DNS, registrar, cloud, repository or identity accounts can be as important as the application itself. Recovery credentials and escalation contacts must not live only inside the compromised system.

Convert business criticality into recovery tiers

Not every component needs the same objective. A tiered plan can focus investment where disruption causes the greatest harm.

Example tier	Service impact	Possible treatment
Critical	revenue, safety, essential service or customer account access stops	tight RTO/RPO, automated monitoring, resilient architecture, frequent exercises
Important	core information or lead capture is impaired	documented restore, tested backups, temporary alternative channel
Standard	lower-impact content or campaign material unavailable	longer recovery objective and scheduled restoration
Archive	historical evidence retained but not needed immediately	protected long-term retention and slower retrieval

The project team should validate the classification with business, technology, risk and service owners. Technical importance is not always business importance. A small postcode eligibility service can block an entire customer journey, while a large image library may be inconvenient but not critical.

Make backups resilient to the incident

A backup stored under the same account, credentials and administrative path as production can be deleted or encrypted during the same compromise. The recovery design should consider separation, least privilege, immutability or offline retention, encryption, retention periods and independent alerting.

The ASD advises that backups should be retained securely and resiliently and protected from modification and deletion by ordinary accounts. Its business-leader data security guidance also recommends aligning frequency and retention with business criticality and periodically testing coordinated restoration.

A practical backup schedule should answer:

What is captured?
How frequently is each component captured?
How long is each version retained?
Where is it stored and in which jurisdiction?
Which identities can read, restore, alter or delete it?
How is backup success independently monitored?
How is integrity verified?
How are privacy, legal hold and data-retention obligations handled?
What happens when storage or credentials are compromised?

The organisation should also confirm how backup arrangements interact with the hosting provider’s service. A provider snapshot can be useful, but it may not include the application-level consistency, off-platform copy, retention or recovery assistance the client assumes.

A restore test is the proof

Backup monitoring proves that a process attempted to create a copy. Only a restore exercise shows whether the organisation can recover an operable service.

The ASD’s technical backup example recommends scoping backups to include the information, software and configuration needed for recovery and regularly testing restoration. The exercise should therefore do more than open a zip file.

A full rehearsal can test:

recovery into a clean, isolated environment
availability of code, data, media, settings and secrets
version compatibility between components
identity, permissions and administrator access
scheduled jobs, search, email and background processing
critical journeys such as forms, checkout and login
integration connectivity and queued-event reconciliation
DNS or traffic-switching steps
monitoring and logging in the recovered environment
elapsed time against the RTO
restored data age against the RPO
communications, approvals and vendor escalation.

The result should be recorded with timestamps, issues, evidence, actual RTO/RPO performance, remediation actions and an owner. A tabletop exercise is valuable for roles and decisions; a technical restore is necessary to prove the system. Mature programmes use both.

Define the recovery runbook and decision authority

During a serious outage, ambiguity consumes time. The runbook should be concise enough to use under pressure and detailed enough to avoid improvising critical steps.

It should identify:

incident detection and declaration criteria
incident commander and decision authority
technical, business, privacy, legal and communications contacts
supplier escalation paths and contract references
containment steps and evidence-preservation requirements
service priorities and recovery sequence
credentials and break-glass access procedures
rollback, restore and failover instructions
validation checks before traffic returns
customer, staff and regulator communication decisions
reconciliation of orders, leads, payments and messages
criteria for closing the incident and completing a review.

Copies should remain accessible when the production platform, identity service or normal document store is unavailable. Access to recovery instructions must still be controlled because they can reveal sensitive architecture and credentials.

Clarify responsibility across client, host and website partner

Recovery often fails at organisational boundaries. The host assumes the application team will restore the software. The application team assumes the host will recover everything. The client assumes both parties monitor the complete customer journey.

A responsibility matrix should distinguish infrastructure, operating system, application, database, content, DNS, certificates, integrations, monitoring, incident command and communications. It should specify who performs the task, who authorises it, who must be consulted and who receives updates.

Emote does not sell or resell hosting infrastructure. Emote can help define application recovery requirements, coordinate with a suitable hosting partner or work with a client’s existing appropriate provider. The client normally contracts and pays the hosting provider directly. That direct relationship should be reflected in the recovery plan, service levels, escalation contacts and evidence available to the client.

Recovery requirements belong in Discovery and procurement

Do not wait until launch to ask whether the proposed platform can meet the required objectives. RTO, RPO, data criticality, hosting responsibilities, integration recovery and testing expectations can materially affect architecture and cost.

For a complex website, ecommerce store or portal, paid Discovery should establish:

service and dependency inventory
business impact and recovery tiers
current and target RTO/RPO
hosting and supplier boundaries
backup and retention requirements
recovery architecture options
monitoring and alert design
test and evidence plan
operating roles and support pathway.

The implementation proposal can then distinguish initial build, eligible warranty corrections and ongoing operational support. A 30-day functional warranty does not create disaster-recovery monitoring, platform maintenance or an incident-response retainer.

Frequently asked questions

Is a daily website backup enough?

It depends on the acceptable data loss, what the backup includes and how quickly it can be restored. A daily database copy may be inadequate for a busy store and excessive for a static archive. Define the RPO first, then design the schedule.

What is the difference between RTO and RPO?

RTO is the maximum acceptable restoration time. RPO is the maximum acceptable period of data loss. One concerns downtime; the other concerns the age of recoverable data.

How often should a website restore be tested?

Set the frequency according to business criticality, change rate, risk and compliance needs. Also retest after material architecture, hosting, integration or deployment changes. The key is a documented cadence and evidence, not an arbitrary annual checkbox.

Can hosting redundancy replace disaster recovery?

No. Redundancy can reduce infrastructure outages but may not protect against corruption, compromise, malicious deletion, faulty deployment or account takeover. Recovery requires separate copies, decisions and tested procedures.

Should backups be stored with the same host?

Provider-managed backups can be part of the design, but consider whether a separate security boundary or off-platform copy is needed. Confirm account separation, deletion protection, retention, jurisdiction and restore access.

Does disaster recovery include third-party integrations?

It should include the website’s dependency on them. The plan may not recover a third party, but it should define degradation, queuing, retry, reconciliation and communications when that service is unavailable.

Who should declare a disaster?

Name an authorised incident commander or decision group in advance. Technical staff can identify failure, but business, legal, privacy and customer impacts may shape the recovery decision.

Is disaster recovery covered by Emote’s website warranty?

No. Completed Emote website implementations include the standard 30-day functional warranty from production go-live unless a signed project-specific agreement says otherwise. That warranty addresses eligible implementation defects. Recovery planning, monitoring, maintenance, incident response and enhancement are separate services.

How Emote can help

The most useful disaster-recovery plan is not the longest. It is the plan that reflects the real website, has authority behind it and has been proven under realistic conditions. Emote can help organisations map the application and integration layer, define recovery requirements and build recovery-aware website delivery and support processes with the client and its hosting provider.

Emote’s website support options provide a useful starting point for discussing the website-side responsibilities that continue after launch.

If recovery assurance currently ends at “backups are enabled”, book a website planning conversation with Emote to discuss the application, integrations and restore evidence.