Backup and Disaster Recovery in the Cloud: Designing for RPO and RTO

Moving to the cloud does not remove the need for backup and disaster recovery. Cloud platforms are highly resilient, but they do not protect you from accidental deletion, ransomware, faulty updates, misconfiguration or the failure of an entire region. Under the shared responsibility model, the provider keeps the underlying infrastructure running, while you remain responsible for your data and how your applications recover. This article explains how to design backup and disaster recovery around two key measures, the recovery point objective (RPO) and recovery time objective (RTO), and how to choose a strategy that balances protection with cost.

RPO and RTO in plain terms

Recovery point objective (RPO) is the maximum amount of data, measured in time, that the business can afford to lose. If your RPO is four hours, you must be able to restore data to a point no more than four hours before the incident.

Recovery time objective (RTO) is the maximum acceptable time between an incident and the service being available again. If your RTO is eight hours, the system must be usable within eight hours of the disruption.

The two are related but distinct. A nightly backup might deliver an acceptable RTO of a few hours for a small system, but an RPO of up to 24 hours, meaning a full day's work could be lost. Lower values for both RPO and RTO generally require more sophisticated, and more expensive, solutions.

Setting targets with the business

RPO and RTO are business decisions, not technical ones. IT can advise on what is achievable and at what cost, but the people who rely on each system must decide how much loss and downtime they can tolerate. A structured approach helps:

1. List your systems and the business processes each one supports.
2. Assess the impact of downtime over different periods: one hour, one day, one week. Consider financial, operational, contractual, regulatory and reputational effects.
3. Assess the impact of data loss. Can lost transactions be re-entered from other sources, or are they gone for good?
4. Group systems into tiers, such as critical, important and deferrable, each with agreed RPO and RTO targets.
5. Record dependencies. A critical application is not recovered until its database, identity service, network connectivity and integrations are also available.
6. Obtain sign-off from business owners so expectations are clear before an incident occurs.

Backup fundamentals that still apply

Cloud tools make backups easier to automate, but the fundamentals have not changed. A widely used rule of thumb is the 3-2-1 approach: keep at least three copies of data, on two different types of storage, with one copy held separately from the primary environment. Many organisations now extend this with an immutable or offline copy and with verified restores.

• Separate the backups from production. Store backups in a different account, subscription or project with separate administrative credentials, so a compromised production account cannot delete them.
• Use immutability. Object lock and immutable vault features prevent backups from being altered or deleted for a defined retention period, which is a vital defence against ransomware.
• Copy across regions. For important systems, replicate backups to a second region to protect against a regional outage.
• Protect software-as-a-service data. Email, file-sharing and collaboration platforms often have limited native retention. Consider a dedicated backup for them.
• Encrypt and control access. Ensure backups are encrypted and that access is limited and logged.

Comparing disaster recovery strategies

Cloud disaster recovery strategies are commonly described in four broad patterns. Each offers a different balance of cost, complexity, RPO and RTO.

Backup and restore

Data is backed up regularly and, in a disaster, infrastructure is rebuilt and data restored. This is the least expensive approach and suits many non-critical systems. RTO is typically measured in hours or longer, and RPO depends on backup frequency. Using infrastructure as code to rebuild environments shortens recovery considerably.

Pilot light

The core of the system, usually the database, is continuously replicated to a recovery region, while application servers are kept switched off or defined in templates ready to launch. RPO can be short because data is replicated continuously, and RTO is reduced because only part of the environment must be started.

Warm standby

A scaled-down but fully functional copy of the environment runs in the recovery region at all times. In a disaster, it is scaled up and traffic is redirected. This offers lower RTO than pilot light, at a higher ongoing cost.

Multi-site active-active

The application runs at full capacity in two or more locations simultaneously, with traffic shared between them. Recovery from the loss of one site can be near-immediate. This is the most expensive and complex option and is usually reserved for systems where even short outages are unacceptable.

Most SMEs use a combination: backup and restore for the majority of systems, with pilot light or warm standby for a small number of genuinely critical ones.

Designing the recovery plan

A disaster recovery plan should be specific enough that a competent person who did not design the system could follow it under pressure. It should include:

• Clear criteria for declaring a disaster and who has the authority to do so.
• Contact details for staff, suppliers and the cloud provider's support channels, stored somewhere accessible if primary systems are down.
• The order in which systems are restored, reflecting dependencies.
• Step-by-step recovery procedures, ideally automated through scripts or infrastructure as code.
• How DNS and network routing will be switched to the recovery environment.
• How data integrity will be validated before users are allowed back in.
• How to fail back to the primary environment once it is restored.
• A communication plan for staff, customers and, where required, regulators.

Testing: the step most organisations skip

A backup that has never been restored is an assumption, not a safeguard. Testing reveals missing permissions, undocumented dependencies, expired credentials and procedures that no longer match reality.

1. Routine restore tests. Regularly restore individual files, databases and virtual machines to confirm backups are usable.
2. Tabletop exercises. Walk through a scenario, such as a ransomware attack or regional outage, with the people involved, and identify gaps in the plan.
3. Partial failover tests. Recover a selected system into the recovery environment and measure the actual RTO and RPO achieved.
4. Full failover tests. For critical systems, periodically fail over the whole service, where it is safe to do so.
5. Record and act on results. Document what worked, what did not and how long each step took. Update the plan and retest.

Conclusion

Effective cloud disaster recovery starts with agreed business targets, not with technology. Define RPO and RTO for each tier of system, then choose the simplest strategy that meets them: backup and restore for most workloads, and pilot light, warm standby or active-active only where the business case justifies the cost. Keep backups isolated and immutable, protect software-as-a-service data, and above all test your recovery regularly. When an incident does happen, a rehearsed plan is what turns a crisis into an inconvenience.