What disaster recovery means
A disaster recovery plan describes how an organization restores its critical systems and data after a serious disruption. The disruption might be a fire or flood at an office, a failed data center, a cyberattack, a major software fault or a human error that deletes important records. The plan answers practical questions: what must come back first, how quickly, from which copies and who does what.
A cloud-based approach uses infrastructure rented from a cloud service provider as the recovery site, instead of (or in addition to) owning a second physical location. This article is a general overview. It is not IT, financial or compliance advice, and the right design depends on the organization.
Two numbers that shape every plan
Recovery planning usually starts with two objectives, set separately for each important system.
- Recovery time objective (RTO): how long the business can tolerate a system being unavailable. An RTO of four hours means the target is to be running again within four hours of the disruption.
- Recovery point objective (RPO): how much recent data the business can afford to lose, measured as time. An RPO of one hour means copies should be made often enough that, at worst, roughly the last hour of changes might be lost.
A simple hypothetical example: suppose an order system is copied to a recovery location every 15 minutes. If a failure happens just before the next copy, up to about 15 minutes of orders could be missing, so the RPO achieved is roughly 15 minutes. If it takes 90 minutes to start the replacement servers and reconnect users, the RTO achieved is 90 minutes. Tighter targets generally need more frequent copying and more standby resources, which costs more.
Common recovery patterns
Cloud providers and consultants describe a spectrum, with terms that vary slightly.
- Backup and restore. Data copies are stored in the cloud, and systems are rebuilt when needed. Cheapest to hold, slowest to recover.
- Pilot light. A minimal core, such as a database that is continuously updated, runs in the cloud, and other components are started on demand.
- Warm standby. A scaled-down but working copy of the environment runs all the time and is enlarged when needed.
- Hot or active-active. Full environments run in more than one place, so failover can be fast, sometimes nearly seamless, at higher cost and complexity.
Failover is the act of switching operations to the recovery environment. Failback is returning to the primary one once it is repaired. Both need planning, since moving back can be as tricky as moving away.
Potential benefits
Avoiding a second physical site. Renting capacity when needed can reduce the up-front expense of buying and maintaining duplicate hardware. This may suit organizations that cannot justify their own recovery data center.
Flexible scaling. Resources can be started only during a test or an emergency in some designs, so spending can follow need. How much is saved depends on the pricing model and the design.
Geographic separation. Recovery environments can usually be placed in a different region from the main site, reducing the chance that one local event affects both.
Automation. Infrastructure can often be described in code and recreated repeatably, which can reduce manual steps under stress.
Easier testing. It can be simpler to build a temporary copy of an environment in the cloud to rehearse a recovery without disturbing production.
Costs and risks to weigh
A balanced assessment includes the downsides.
- Ongoing costs. Storage, data transfer, standby resources and licensing add up. Surprises in cloud pricing are common, so estimates should be checked carefully against actual usage.
- Complexity. Hybrid arrangements, networking, identity and dependencies between systems can make recovery harder than it looks on paper.
- Dependence on a provider. Relying on one provider introduces concentration risk, and moving away later can be hard because of vendor lock-in. Provider outages, though uncommon, do happen.
- Shared responsibility. Under the shared responsibility model, the provider secures its infrastructure while the customer remains responsible for configuring, protecting and restoring its own data and workloads.
- Bandwidth limits. Restoring large volumes of data over a network can take longer than expected.
- Security exposure. Recovery environments must be protected as carefully as production, including access control and encryption. Attackers who gain administrative access may try to delete recovery copies.
- Legal and location issues. Where data is stored may matter for contractual or regulatory reasons, a topic related to data sovereignty.
- Application fit. Older or specialized systems may not run easily in the cloud.
Testing is the point
A plan that has never been exercised is an assumption. Useful practices include:
- Documenting the order in which systems are restored, with their dependencies.
- Running recovery tests on a schedule, from a simple restore of one dataset to a full failover exercise.
- Recording how long steps really take and comparing them to the stated RTO and RPO.
- Keeping contact lists, access credentials and runbooks available even if main systems are down.
- Updating the plan when systems, staff or providers change.
Failures found in a test are inexpensive; failures found in a real emergency are not.
How it relates to related ideas
Backups are the foundation, and disaster recovery builds on them by adding the ability to run systems elsewhere. A response to a specific security event follows an incident response process, which feeds into recovery decisions. Not every organization needs a full cloud recovery environment; for many small teams, well-tested offsite backups and a written restoration procedure may be proportionate. Outcomes cannot be guaranteed, and a professional assessment of the organization’s own risks and obligations is advisable.