Disaster Recovery in the Cloud: RTO/RPO, Pilot Light, Warm Standby, and a DR Plan for SMBs

Disaster Recovery in the cloud for SMBs does not start with choosing the “most reliable” architecture, but with two business questions: how much downtime the company can afford and how much data it can lose without unacceptable harm. The answers are expressed through metrics such as RTO and RPO, but they cannot be set as a single value for the entire infrastructure: an online store, CRM, payments, email, and archives all have different levels of criticality.

Backups alone are often not enough. A backup helps restore data, but it does not guarantee that the application will quickly come back online along with DNS, access permissions, certificates, integrations, and the payment environment. That is why SMBs typically use a mixed approach: non-critical systems remain on a backup-only recovery model, important services are moved to pilot light, and revenue and customer commitments are protected through warm standby.

An active-active approach is rarely needed—only where the cost of downtime exceeds the ongoing complexity of such an architecture. At the same time, an operational recovery plan (DRP, Disaster Recovery Plan) is not just a diagram on paper, but a validated plan: critical services, dependencies, recovery sequence, responsible owners, activation criteria, and regular testing.

What Disaster Recovery Is in the Cloud and How It Differs from Backup, HA, and Business Continuity

Backups are in place, the cloud bill is paid, and monitoring was green before the incident. Then the service will not come back up: DNS points to the wrong place, access is tied to an unavailable SSO, the certificate has expired, the payment integration is unresponsive, and the recovery procedure lives in the head of an engineer who is offline today.

On paper, the company is “protected.” In practice, the business cannot accept orders, cannot access the CRM, and cannot tell customers when service will be restored.

The cloud helps teams provision resources quickly, store copies, replicate data, and launch standby environments. But it does not know which service is most critical to the company: the online store, the CRM, inventory management, or even email. And it certainly will not appoint the person responsible for making the failover decision during an incident.

Disaster Recovery is the managed recovery of IT services after a major failure: a cloud region outage, loss of the primary environment, a configuration error, a security incident, or the unavailability of an important provider. The goal is not just to restore data, but to restore the business function: the service accepts orders, employees can sign in, integrations work, and the responsible people understand each next step.

To avoid building a plan around the wrong term, it is useful to separate related practices.

DR does not replace backup, high availability, or a business continuity plan. It connects them to a specific goal: bringing back the service required for sales, support, production, or contract fulfillment.

For SMBs, this distinction is especially important: budgets are limited, teams are small, and infrastructure often consists of cloud services, SaaS platforms, and external providers. When backup, HA, and DR are not collapsed into the single word “reliability,” the false sense of security disappears and a basis for calculation emerges.

RTO and RPO: translating downtime and data loss into business terms

Once the boundaries have been defined, the key question is how quickly recovery needs to happen and how much data loss the business can tolerate. IT alone cannot answer this. A server can be brought back up in an hour, but during that hour the company may already have lost payments, breached an SLA, or forced the sales team to collect requests manually from email and messaging apps.

Two metrics are needed here.

RTO (Recovery Time Objective) — target recovery time. This is the maximum allowable time during which a specific service can be unavailable without causing unacceptable damage. For an online store, two hours of downtime for the cart and payment services may be critical. For an internal contract archive, the same two hours, and sometimes even a full day, do not block ongoing sales.

RPO (Recovery Point Objective) — the target recovery point. It is not concerned with the duration of downtime, but with the extent of potential data loss: how far back the business is prepared to roll back after a failure. If the RPO is one hour, the company accepts the risk of losing changes made within the last hour at most: orders, CRM updates, payment statuses, and document edits. If this data cannot be restored from external systems or correspondence, the cost of that hour becomes material.

RTO and RPO cannot be set as a single value for the entire company. In one SMB company, an online store may require recovery within tens of minutes and minimal loss of orders. A CRM system may tolerate several hours of downtime if managers temporarily record deals manually. File storage containing archives may take longer to restore if it is not involved in current contracts.

Before setting targets, the business and IT should answer the following questions together:

• How much money is lost per hour of downtime;
• Which obligations to customers and partners are breached;
• Whether temporary manual work is possible;
• Which data cannot be recovered from external sources;
• Which services block sales, support, or contract fulfillment;
• Where downtime turns into reputational damage.

These questions change the meaning of the phrase “how much does cloud DR cost.” A more precise question is: what level of risk is the company prepared to accept, and what protection is truly worth paying for.

Zero downtime and zero data loss come at a cost: a more expensive architecture, continuous replication, complex testing, higher demands on the team, and stricter change discipline. That is why RTO and RPO are needed not for a polished table, but as a filter: where recovery from backups is sufficient, where a standby environment is required, and where near-continuous operation is justified by revenue, contracts, or regulatory requirements. RTO and RPO must always be defined jointly by both business and IT departments.

Why SMB services cannot all be protected the same way

If CRM, payments, and the document archive all receive the same level of protection, the business is almost certainly making a mistake. It is either overpaying for rapid availability of systems that can be restored later, or cutting costs where downtime immediately turns into lost orders, manual work, and contractual claims.

After calculating RTO/RPO, the next step is not a list of servers, but a map of business functions. Criticality is determined not by how “important” a server appears, but by what will break in the business process.

Website or Online Store

A website supports the storefront, request intake, shopping cart, and checkout process. If sales are handled online, its criticality is usually high: downtime quickly affects revenue and incoming requests.

Typical dependencies include DNS, certificates, the product database, a payment gateway, external APIs, a CDN, and access to the admin panel.

CRM

The CRM system manages deals, communications, and customer history. For sales and support teams, it is often one of the key services: without it, managers lose context, cannot see statuses, and have to process requests manually.

Dependencies typically include IAM/SSO, email, telephony, and integrations with the website, warehouse, and internal systems.

Email

Email is used for correspondence, notifications, confirmations, and communication with customers. Its criticality depends on how heavily the company relies on email for sales, support, and operational processes.

During recovery, key considerations include DNS records, accounts, anti-spam protection, administrator access, and backup communication channels.

Order and Customer Database

The order and customer database stores sales records, statuses, obligations, and transaction history. This is usually a mission-critical layer: the application can be brought back up, but without up-to-date data, the business will not be able to accept orders and serve customers properly.

Key dependencies include the data store, backups, replication, access keys, the network, and the team’s permissions to perform recovery.

File Storage

File storage stores contracts, documents, and working files. Its criticality may be medium or high: archives can sometimes be restored later, while documents for active contracts may be needed immediately.

Dependencies include IAM/SSO, access permissions, VPN, encryption keys, and a clear procedure for restoring the required folders rather than the entire storage system at once.

Payments

The payment layer is responsible for payments, refunds, and cash flow. For online sales, it is a critical service: the website may be available, but without payment processing, the business still cannot fully accept orders.

Key elements here include the payment gateway, secrets, the bank’s API, certificates, allowed IP addresses, and the provider’s support contacts.

This type of map shows that SMBs rarely need the same level of DR for every system. They first protect services that directly affect money, customers, and obligations, and then allocate resources to less critical functions.

Dependencies are a separate layer. They are often treated as technical details until a restored service turns out to be unavailable because of DNS, an invalid certificate, a closed network, or SSO that remained in the failed environment.

This is especially noticeable in cloud DR: virtual machines can be brought up quickly, but without access to the cloud account, secrets, keys, VPN, and the necessary team permissions, recovery comes to an immediate halt.

Why backup-only does not cover the entire recovery path

The criticality map shows that services have different dependencies. During an outage, this turns into a chain of blockers: the online store database has been restored from a backup, the order data is in place, but new purchases still do not go through. The application will not start because the secrets are outdated, DNS points to the old environment, SSO is unavailable, and the payment gateway rejects requests from the new address.

Backup-only — an approach in which primary protection is based on backups. The company stores data and, in the event of a failure, redeploys the service from scratch: in the previous environment if it is still available, or on a new cloud platform. This is the cheapest and most straightforward entry-level DR option: fewer persistent resources, simpler operations, and a lower cloud bill.

The problem lies in the scope of responsibility. Backup helps you get close to the required RPO: there is a point to which the data can be restored. But by itself, it does not guarantee RTO, because recovery time is spent on more than just loading a dump or a disk snapshot. Once the data is restored, you still need to assemble a working system around it:

• Compute resources, images, application versions, and configurations;
• Network, routes, VPN, and firewall rules;
• IAM/SSO or emergency admin access;
• DNS records and the traffic failover procedure;
• Certificates, secrets, and API keys;
• Queues, integrations, external APIs, and payment gateways;
• Monitoring, logs, and technical validation;
• Business validation: the order was created, the CRM opened, and the payment was confirmed.

If these elements are not documented in advance, backup-only becomes a manual project at the most stressful moment. On paper, the data has been preserved, but the business remains at a standstill.

This does not make backup-only a bad strategy. For archives, internal reports, file storage systems with no time-sensitive operations, test environments, and non-critical websites, it is often a reasonable choice. But for order databases, payments, operational CRM, customer-facing SaaS, and e-commerce processes, this approach can easily create a false economy.

Four Cloud DR Strategies as a Spectrum of Cost and Recovery Speed

The next decision is the required level of readiness for the standby environment. This is not a set of independent architectures, but a spectrum: the closer the standby environment is to a production-ready state before a disaster, the less manual assembly is required at the time of failure, and the higher the ongoing costs for infrastructure, replication, monitoring, automation, and testing.

At a high level, this scale can be represented as follows: backup-only → pilot light → warm standby → active-active. On the left, ongoing costs are lower, but more manual work is required during an incident. On the right, recovery is faster, but cost, complexity, and team requirements are higher.

Backup-only

The data is preserved, but the environment is rebuilt after a disaster. Before the incident, there are backups and, at best, deployment instructions. When a disaster occurs, the team brings up the infrastructure, restores the data, configures the network and access, and verifies the application.

RTO is usually the longest in this model, while RPO depends on the backup frequency. This approach is suitable for archives, reporting, and services the business is prepared to wait for.

The next level is not a full recovery site, but a preconfigured “core” that can be quickly expanded into a working environment.

Pilot light

The standby core is already in place. Basic components are prepared in advance in the cloud: the network, infrastructure templates, minimal databases or replicas, and key configurations. During an outage, this core is scaled up to production capacity: compute resources are added, applications are started, and traffic is switched over.

RTO is shorter than with a backup-only approach, but there are ongoing costs for the minimal environment and regular testing. For SMBs, this is often a reasonable level for CRM, a ticket portal, and internal sales systems.

If the business needs even less manual setup during an outage, the standby environment should not simply wait to be deployed; it should already be running, albeit in a lightweight mode.

Warm standby

A scaled-down copy is already running. The standby environment is always active, but at a smaller scale: it handles test traffic or a small load, receives up-to-date data, and is monitored. In the event of an outage, it is scaled up and promoted to the primary role.

RTO becomes significantly shorter, and RPO is closer to the current state of the data. However, operations become more complex: you need to monitor synchronization, application versions, database schemas, and cloud limits. This approach is suitable for an online store, customer portal, order database, or B2B portal.

The most expensive option is when the standby site is no longer merely a backup and participates in operations continuously.

Active-active

Multiple sites handle the workload simultaneously. In this model, the backup environment is no longer truly “backup”: the sites run in parallel, traffic is distributed between them, and data is synchronized almost continuously. In an incident, failover looks like workload redistribution.

But the complexity is there every day: data consistency, conflicting writes, network latency, monitoring, failure testing, an expensive architecture, and a team capable of managing it. For SMBs, active-active is justified only when downtime costs more than ongoing complexity.

Fast DR is more expensive because the business is buying time in advance. It pays not only for servers, but also for environment readiness, up-to-date configurations, validated replication, and people who regularly test the scenario.

DR Strategy Selection Matrix by RTO/RPO, Budget, and Complexity

On paper, it is tempting to choose the fastest option for every system. In practice, an SMB can rarely sustain a single DR strategy across the entire company: an online store needs fast protection for orders and payments, the CRM can operate under a lighter-weight scenario, and internal reporting can safely wait to be restored from a backup.

The selection matrix is not intended to identify the “best” strategy, but to provide an initial mapping of service requirements to cost and complexity. First, RTO and RPO are defined for a specific service; then the ongoing budget is assessed: cloud resources, replication, automation, monitoring, testing, and the team’s time and composition.

Backup-only

When appropriate: archives, reporting, non-critical files, test environments, and services that the business is prepared to restore over hours or days.

Typical RTO/RPO: RTO — hours or days. RPO — hours or up to a day, depending on backup frequency.

Cost and complexity: the ongoing budget is low, and operation until a failure is simple. The main complexity is shifted to the recovery phase.

Limitation: it is easy to miss the RTO due to manual setup of the environment, network, access permissions, DNS, and dependencies.

Pilot light

When it is appropriate: CRMs, ticket portals, internal sales systems, and important services that do not require immediate availability but cannot be rebuilt from scratch.

Typical RTO/RPO: RTO is measured in tens of minutes or hours. RPO is measured in minutes or hours, depending on replication.

Cost and complexity: the budget is low to medium. Complexity is moderate: the backup kernel must be kept up to date and checked regularly.

Limitation: scaling and failover require a pre-tested procedure. If the core is outdated, recovery once again becomes a manual project.

Warm standby

When appropriate: order database, customer account portal, B2B portal, payment environment, and systems that directly affect revenue or obligations to customers.

Typical RTO/RPO: RTO: minutes or tens of minutes. RPO: minutes, sometimes closer to the current state of the data.

Cost and complexity: the budget is medium or high. Complexity is high: the backup environment runs continuously, but at a reduced size.

Limitation: continuous monitoring of synchronization, application versions, database schemas, cloud limits, and the team’s readiness to switch over is required.

Active-active

When it is appropriate: mission-critical SaaS services, online sales with high downtime costs, strict SLAs, and systems where even a brief outage costs more than the ongoing complexity.

Typical RTO/RPO: RTO — seconds or minutes. RPO — seconds or minutes.

Cost and complexity: the budget is very high, and the complexity is also very high. The team must continuously maintain the distributed architecture, monitoring, and failover tests.

Limitation: expensive architecture, complex data consistency, conflicting records, network latency, and a high cost of errors in changes.

For SMBs, the picture is usually mixed: non-critical services remain backup-only, important processes that do not require immediate recovery move to pilot light, and systems with a direct impact on revenue and obligations use warm standby. Active-active makes sense only where downtime is more expensive than the ongoing complexity, not simply because it is the “most reliable” option in the table.

The main mistake is choosing a DR approach based on the strategy name rather than the cost of downtime and the team’s ability to maintain the selected operating model. The inexpensive option defers the work until an outage occurs. The fast option requires paid infrastructure, change discipline, and regular validation in advance.

Example of a Minimal DR Plan for an SMB

The matrix answers the question of which strategy to choose. But during an incident, the team needs an actionable runbook: what qualifies as an incident, who makes the decision, which services to bring up first, which dependencies to check, and which indicators the business will use to confirm recovery.

Below is an example of a minimal DR plan for an SMB that sells through its website, manages deals in a CRM, and accepts online payments.

Initial Assumptions for the Example

The company uses a cloud-hosted website or online store, a database of orders and customers, a CRM system, corporate email, file storage with contracts, an external payment gateway, SSO/IAM, and DNS hosted by a separate provider.

A single strategy is not chosen for everything. The online store and order database use warm standby because downtime directly affects revenue. The CRM system operates under a pilot light model: managers can temporarily record inquiries manually, but extended downtime hurts sales. Email and file storage remain on backup-only protection or the SaaS provider’s standard protection if the business can tolerate a longer recovery time.

Payments require separate attention: part of the environment is handled by an external provider, so the plan must include support contacts, keys, allowlisted addresses, and verification of a test payment.

Criteria for Initiating the DR Scenario

The DR plan should not be initiated for every brief outage. Example criteria may include the following:

• The primary site or order database has been unavailable for more than 15 minutes, and no recovery estimate is available;
  
• A cloud region, availability zone, or key network is unavailable, and the provider has confirmed a widespread incident;
  
• Data has been corrupted or encrypted, and recovery from a clean restore point is required;
  

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure



Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans



Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus



Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster


• Service unavailability violates customer commitments or blocks order acceptance;
  
• The incident technical lead and the service business owner have agreed to initiate DR.

It is better not to leave the decision to a single engineer. At a minimum, it should be made by two people: the incident technical lead and the business owner of the affected service.

Priority 1. Team access to cloud and DR tools

The team must first gain access to the tools that will be used to restore the environment: the cloud account, DNS console, secrets manager, monitoring, documentation, and provider contacts.

The target RTO for this layer is 15–30 minutes. RPO does not apply here because this is not about data, but about the ability to manage recovery.

The success criterion is simple: the team has logged in to the cloud without using the failed SSO, can modify DNS, networking, and secrets, and can open the up-to-date instructions.

Priority 2. Order and Customer Database

The order and customer database has a warm standby because sales, order statuses, and customer obligations depend on it. The target RTO is 30–60 minutes, and the RPO is 5–15 minutes.

In the event of a failure, the team checks the replica, data integrity, encryption keys, network, and secrets. If the replica is corrupted, it must be restored from a clean restore point. The application is then switched to the standby database.

Success criterion: recent orders are visible, the application connects to the standby database, and the data does not appear corrupted or incomplete.

Priority 3. Online Store

The online store also runs in a warm standby model. The target RTO is up to 60 minutes, and the RPO for orders is 5–15 minutes.

In the event of an outage, the standby environment is scaled up, and the configurations, DNS, certificates, CDN, product database, and connection to the payment processing environment are verified. DNS or the load balancer is then switched over, and a test order is placed.

Success criteria: the site loads, an order is created, a notification is sent to the customer, and the team sees the event in the system.

Priority 4. Payments

The payment environment is protected by warm standby for its part of the infrastructure and by a separate procedure agreed with the provider. The target RTO is up to 60 minutes. The RPO depends on how the payment provider stores and synchronizes transaction statuses.

In the event of a failure, API keys, certificates, allowed IP addresses, gateway availability, and support contacts must be checked. It must also be verified separately whether the standby environment is enabled on the payment provider’s side.

Success criterion: a test payment is completed, or payment statuses are synchronized correctly.

Priority 5. CRM

The CRM can be moved to a pilot light model if managers can temporarily record requests manually. The target RTO is 2–4 hours, and the RPO is approximately 1 hour.

In the event of an outage, the CRM is deployed from a prepared template, the data is connected, and SSO/IAM, email, telephony, and website integrations are checked. If recovery is delayed, manual request logging is activated.

Success criterion: managers can log in to the CRM, see customers and deals, and new requests are not lost.

Priority 6. Email

Email can remain under backup-only protection or the SaaS provider’s standard protection if the business can tolerate a longer recovery time. The target RTO is about 4 hours; the RPO depends on the provider.

In the event of an outage, check the provider’s status, administrator access, DNS records, spam filtering, and notification delivery. If necessary, switch DNS or temporarily use a backup communication channel.

Success criterion: inbound and outbound email are working, and critical notifications are being delivered.

Priority 7. Contract File Storage

File storage can usually be restored later if it does not block current sales or contract fulfillment. The target RTO is one business day, and the RPO is up to 24 hours.

In a disaster, the entire storage system is not restored at once. Instead, critical folders are restored first: contracts, documents for current customers, and files required for operations and support. Access permissions, SSO/IAM, encryption keys, and VPN are then verified.

Success criterion: the responsible departments can open the required documents and understand which data will be restored later.

A minimal DR plan does not have to be a large document, but it must connect technical recovery with business validation. If, after failover, no one has verified order creation, a manager’s login to the CRM, and payment processing, the service cannot be considered restored simply because the servers are “green.”

Step-by-step recovery procedure

Priorities show what to restore first. But during an outage, the team also needs a sequential plan: who declares the incident, who makes decisions, who switches traffic, and who confirms that the business function is working again.

1. Log the incident and open a shared communication channel. A dedicated chat or conference bridge (war room) is needed for IT, the business, and the incident manager. Immediately document where the current status is maintained and who is authorized to provide external comments.
   
2. Appoint an incident manager. The term "incident owner" is sometimes used. This person coordinates recovery: who handles the cloud, who contacts providers, who reports status to the business, and who makes the decision to switch over.
   
3. Verify emergency access. The team must log in to the cloud, DNS panel, secrets manager, monitoring system, and provider accounts. This access must not depend solely on SSO, which may be part of the incident.
   
4. Stop the situation from deteriorating. If data corruption or encryption is suspected, do not restore over the primary environment. Resources must be isolated, logs preserved, and a clean recovery point identified.
   
5. Restore the data of the most critical service. In this example, this is the orders and customer database. The replica currency, data integrity, and application connectivity are verified.
   
6. Bring up or scale the standby application. For warm standby, the standby environment is scaled up to production size. For pilot light, the application is deployed from prepared templates. For backup-only, the environment is assembled according to the instructions.
   
7. Check dependencies. DNS, certificates, secrets, API keys, routes, VPN, access rights, integrations with the bank, email, and CRM. This is often where the actual RTO is lost.
   
8. Switch traffic. The team changes DNS, the load balancer, or routing. The plan must specify the person authorized to perform this action and the rollback method.
   
9. Perform technical and business checks. The technical check shows that the application is responding, the database is available, the logs contain no critical errors, and monitoring detects the backup environment. The business check confirms that the order is created, the payment is processed, the customer receives a notification, and the manager sees the request.
   
10. Communicate the status to the business and client teams. Sales, support, and management should understand which features are already working, which data may be incomplete, and when the next update will be provided.
    
11. After stabilization, conduct a post-incident review. The team records what worked, what delayed recovery, which access rights or dependencies were overlooked, and which RTO/RPO targets proved unrealistic.

This procedure does not replace technical instructions, but it keeps the team from descending into chaos. During an outage, it is important not only to “fix it,” but also to maintain control: who decides, who acts, who verifies, and who reports the status.

Responsible Parties and Contacts

In a small business, roles are often combined, but they still need to be explicitly named in the DR plan. If the plan simply says “IT,” then during an incident people will start figuring out who changes DNS, who calls the provider, and who confirms that the CRM can be made available to managers.

Minimum set of roles:

• Incident Manager — coordinates recovery, tracks status, and makes technical decisions within the plan;
  
• Service business owner — confirms criticality, approves DR activation, and verifies the business function;
  
• Cloud engineer or operations engineer — provisions the backup environment, network, load balancers, and routes;
  
• Data Administrator or DBA — responsible for the database, replication, backups, and integrity checks;
  
• System administrator — responsible for access management, SSO/IAM, email, file storage, and user permissions;
  
• Finance lead — verifies payments, reconciles statuses, and communicates with the bank or payment provider;
  
• Communications lead — reports status to management, sales, support, and, if necessary, customers and the PR team.

Contacts should be listed alongside the roles: phone number, backup messaging app, email, cloud provider account, contract number, provider status pages, and support contacts for DNS, the bank, the payment gateway, and key SaaS services.

This information should not be stored only in the primary corporate system. If that system itself becomes unavailable, the team must not lose the instructions, contacts, and emergency access credentials along with it.

How to Test a DR Plan So It Doesn’t Remain Hypothetical

An untested DR plan is only a hypothesis. For SMBs, a reasonable minimum is to run a recovery test once per quarter for critical services and once every six months for less critical ones. If the infrastructure changes frequently or customer SLAs become stricter, testing frequency should be increased.

A test does not have to involve a full production failover every time. You can alternate between different formats, from a controlled walkthrough of the procedure to a limited failover to the standby environment.

Tabletop Scenario Review

The team walks through the DR plan step by step and identifies gaps before a real incident occurs: who makes the decision, where the contact details are stored, what access permissions are required, and which activation criteria are sufficient.

This format is suitable for all services, especially email, file storage, reporting, and less critical systems. It helps quickly determine whether roles, contacts, instructions, and the recovery sequence are up to date.

Technical Recovery in an Isolated Environment

The service is brought up from a backup or replica without switching real users over to it. This is a safe way to verify that the backup is actually readable, the application starts, the database connects, and permissions and configurations have not become outdated.

For critical services—such as an online store, order database, payment systems, and CRM—this type of test should be performed at least once per quarter. It is important to record the actual RTO/RPO, errors in the instructions, missing access permissions, and dependency issues.

Partial Dependency Test

Sometimes the problem is not with the data or the application, but with the environment. For this reason, emergency access, DNS procedures, certificates, secrets, routes, VPN, access to the payment provider, and the status pages of external services should be tested separately.

This type of test is useful even without restoring the application. It shows whether the team can manage the emergency environment at all if the primary SSO, network, or corporate documentation becomes unavailable.

Full-scale exercise

The most realistic option is to fail over a test or limited environment to the standby environment, followed by both technical and business validation. The team does not just bring servers online; it tests the entire scenario end to end: an order is created, the payment is processed, a notification is sent to the customer, and the manager sees the request in the CRM.

A full-scale exercise does not necessarily need to be run often, but it is especially valuable for services with demanding RTO/RPO targets and customer commitments. It shows how closely the plan matches the actual recovery speed.

After any test, it is important to record not only that the check was performed, but also the outcome: the actual recovery time, data loss, errors in the instructions, missing access permissions, and issues with DNS, certificates, secrets, integrations, and manual approvals.

Tests are not needed just to tick a box; they are needed to compare the promised DR and RTO/RPO with reality. If the plan promises to restore an online store within an hour, but the test takes three hours because of DNS, secrets, and manual approvals, that is not a failure. It is a useful reality check before a real outage occurs.

Conclusion

For SMBs, cloud disaster recovery is not about finding the “most reliable” architecture, but about choosing a reasonable trade-off between the cost of downtime, acceptable data loss, budget, and the team’s capabilities. Backup-only, pilot light, warm standby, and active-active differ not only in recovery speed, but also in ongoing cost, operational complexity, and testing requirements.

A practical DR approach starts with RTO/RPO targets for specific services and ends with a verifiable plan: recovery priorities, dependencies, responsible parties, provider contacts, activation criteria, and regular tests. If the plan has not been tested, it remains an assumption. If it has been tested, the business gets more than just backups: it gets a clear scenario for returning to work.

FAQ

How does Disaster Recovery differ from regular backups?

A backup preserves data and provides a restore point. Disaster Recovery is broader: it defines how to restore the application, network, access permissions, DNS, certificates, integrations, and the business process itself.

If you only have a backup, the data can be restored, but the service may still not come back online quickly. Effective DR requires a recovery sequence, assigned responsibilities, dependencies, and verification that the service is once again performing its business function.

Can a single RTO and RPO be set for the entire company?

Technically, yes, but in practice this is almost always a mistake. A CRM system, online store, email, payments, and file archive each have different downtime costs and different tolerances for data loss.

It is better to define RTO and RPO by service. This way, the company does not overpay to protect non-critical systems or cut costs where downtime immediately affects sales, customer support, or contractual obligations.

When is backup-only sufficient for an SMB?

Backup-only is suitable for systems whose downtime does not block current operations: archives, reporting, non-critical file storage, test environments, and services that the business is prepared to take longer to restore.

For an order database, payment systems, an operational CRM, a customer portal, or an online store, backup-only is often not enough. The data can be restored, but the actual RTO may not be met because of manual configuration of networking, access rights, DNS, certificates, secrets, and integrations.

What is the difference between pilot light and warm standby?

With pilot light, a standby core is prepared in the cloud in advance: the network, infrastructure templates, minimal databases or replicas, and key configurations. During an outage, this core is scaled up to production capacity, and traffic is switched over to it.

With warm standby, the standby environment is already running continuously, but usually at a smaller scale. It receives up-to-date data, is monitored, and is scaled up to full production capacity during an outage. This option is faster, but more expensive and more complex to operate.

How can you tell whether a DR plan actually works?

A DR plan needs to be tested regularly. For critical services, a reasonable minimum is once per quarter; for less critical services, once every six months. The format can vary: a tabletop scenario review, recovery in an isolated environment, a partial dependency test, or a full-scale exercise.

A plan can be considered operational only after validating the actual RTO and RPO, emergency access, DNS procedures, certificates, secrets, integrations, and business workflows. If, after failover, an order can be created, a payment is processed, the CRM is accessible, and the responsible teams understand the next step, the DR plan is closer to reality than to assumption.

Sources

1. AWS — Disaster Recovery of Workloads on AWS: Recovery in the Cloud

2. Microsoft Azure — What are business continuity, high availability, and disaster recovery?

3. Google Cloud — Disaster recovery planning guide

4. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems