A small or mid-sized business (SMB) has three proportionate disaster recovery options: restore-tested backups, a warm standby in a second region, or an active-active design across two regions. The right option depends on two numbers the business can defend: how long it can be down, and how much recent data it can lose. For most SMBs whose contracts require recovery in minutes, warm standby is the proportionate answer. If the business can tolerate hours of downtime and restores are proven, tested backups are enough, and active-active is rarely justified at this size.
This comparison is for the chief technology officer (CTO), IT director or founder who has received a contract clause, a security questionnaire or a request for proposals (RFP) asking for recovery objectives.
What do RTO and RPO mean, and who sets them?
Recovery time objective (RTO) is the longest the service may stay down after a disaster before it runs again. Recovery point objective (RPO) is the amount of recent data the business accepts losing, measured as time. An RPO of one hour means up to one hour of writes may be gone after recovery.
Both numbers are business decisions with a technical price. The business sets them from the cost of downtime, contract terms and what customers accept. Engineering then says which design meets them. The knowledge base article on translating RTO and RPO for a non-technical CEO gives a way to run that conversation.
Disaster recovery (DR) covers the loss of a whole site or region, or the loss of the data itself. High availability (HA) is a different purchase. HA keeps a service running when one server fails inside a region, which is the job of a clustered environment. A cluster does not help when the region is unreachable or a database is deleted by mistake.
Disaster recovery as a service (DRaaS) means a provider designs, operates and tests that recovery setup for you.
What are the disaster recovery options for an SMB?
An SMB has three realistic disaster recovery designs: restore-tested backups, warm standby and active-active. Rebuilding from backups is sometimes called cold standby or backup and restore.
| Option | How it works | Recovery time | Data at risk | Operating burden |
|---|---|---|---|---|
| Restore-tested backups | Backups are copied off-site. After a disaster, the infrastructure is rebuilt and the data is restored. | The duration of a full rebuild and restore. Measure it. | Everything written since the last good backup | Low: backup monitoring and scheduled restore tests |
| Warm standby | A second region runs at reduced capacity and receives replicated data continuously. A runbook promotes it. | Minutes in a drilled design | The replication lag at the moment of failure | Medium: lag monitoring, keeping the standby in step with releases, regular drills |
| Active-active | Two regions serve live traffic at the same time. | Can approach zero for the loss of one region | Depends on how conflicting writes are reconciled | High: two live stacks, conflict handling, constant attention |
| Option | Choose when | Avoid when |
|---|---|---|
| Restore-tested backups | The business can tolerate hours of downtime and restores are proven | A contract names an RTO shorter than your measured restore |
| Warm standby | A contract, a customer or the cost of downtime requires recovery in minutes | Nobody will own the drills, so the standby will drift from production |
| Active-active | Minutes of downtime carry severe cost and the application was designed for multi-region writes | The goal is to satisfy a questionnaire or to look strong on a diagram |
When are restore-tested backups enough?
Restore-tested backups are enough when two conditions hold. The business can tolerate the time a full recovery takes, and someone has proven that the recovery works.
A backup job that reports success says nothing about whether the data restores or how long the restore takes. The test is an end-to-end restore to a clean target, timed and written down. The knowledge base article on how to know your database restore actually works covers the method.
The measured restore time is your real RTO, and the interval between backups is your real RPO. If both sit inside what your contracts and customers accept, do not buy a second region. Spend the effort on off-site copies, scheduled restore tests and a written runbook. Ask any backup provider where the copies live, how long they are retained, and whether an attacker with production access could delete them.
When should an SMB choose warm standby?
An SMB should choose warm standby when a contract or the cost of downtime requires recovery in minutes, and tested backups cannot meet that. In a warm standby, the second region is already provisioned, the database replicates to it continuously, and a documented signal starts the promotion.
Three design facts matter before buying one.
- Replication is usually asynchronous. The standby trails the primary by a small, monitored lag, so some recent writes can be lost in a failover. A sound design writes down which data is in lockstep and which trails.
- The standby is sized for steady state after a failover, not for the peak hour. That choice keeps the operating cost reasonable, and the business should accept it knowingly.
- An untested standby drifts. Releases, configuration and secrets have to reach both regions. A scheduled drill that performs a real failover is the only evidence that the standby still works.
On platforms with several availability zones inside one region, a multi-zone deployment is usually a cheaper first step, although it does not protect against the loss of a region. See the knowledge base article on multi-AZ versus multi-region for Amazon RDS and Aurora.
When is active-active worth it, and when is it not?
Active-active is worth its cost when minutes of downtime carry severe consequences and the application was designed to accept writes in two regions. Few SMB applications meet the second test.
The cost is in operations as much as in infrastructure. Two live regions create split-brain risk, where each region believes it is the primary. Writes that land in both regions have to be reconciled. Writes that wait for confirmation from the other region are slowed by the distance between the two.
Do not buy active-active to satisfy a security questionnaire. A reviewer asks for recovery objectives, a replication model and the date of the last drill. A documented warm standby with a drilled manual failover answers all three. The article on the infrastructure evidence buyers expect after a failed security questionnaire lists what else reviewers look for.
Is automatic failover safe?
For most SMB workloads, automatic failover between regions is not the safer choice. Automatic failover relies on health signals, and health signals are sometimes wrong. Flapping checks, partial outages and network blips can trigger a cutover that was not needed. A wrong automatic cutover is an outage of its own.
The common alternative is a human acknowledgement. Monitoring raises the alert, an on-call person confirms the primary is down, and a written runbook drives the promotion and the change in the domain name system (DNS). DNS is the usual lever for sending traffic to the standby. The knowledge base compares a managed load-balancing service with a self-hosted multi-region load balancer for that layer.
What RTO and RPO are realistic for a small SaaS company?
Realistic numbers are the ones a drill has measured. A 30-person software-as-a-service (SaaS) company should not copy a vendor’s figure into a contract.
For restore-tested backups, time a full restore and use that result. For a warm standby with monitored asynchronous replication, recovery in minutes is a defensible design target. Stack Harbor’s Multi-Region DR page gives an illustration. It says an RTO around fifteen minutes and an RPO around five minutes for application data is typically defensible, give or take, depending on the data tier and the workload. The same page says the specific numbers are scoped in an assessment. Those figures are not a commitment from Stack Harbor or any other provider, and asynchronous replication does not deliver an RPO of zero.
Before a number goes into a contract, a named owner in the business should have signed it off and a drill should have measured it. The wording should also match what the provider’s own agreement says.
How should you pick the second region?
Pick the second region by residency rules first, latency second and existing cloud footprint third.
For a Canadian workload with a residency requirement, the standby and the backups usually have to stay in Canada too. A Québec organization should note that a standby outside Québec places a copy outside the province, which its privacy officer may need to assess. The article on Canadian data residency requirements for a hosting provider covers the clauses to ask for.
What drives the cost of disaster recovery?
Disaster recovery cost comes from five drivers, and compute in the second region is only one of them.
- Standby capacity. A warm standby pays for servers and databases before they are needed.
- Replication and data transfer. Many cloud platforms charge for data transferred between regions, and replicated data is stored twice.
- Duplicate tooling. Monitoring, logging, secrets management and deployment pipelines have to reach both regions.
- Application changes. Sessions, uploads and scheduled jobs that assume one region need rework. This item is easy to underestimate.
- Drills and operating attention. Each drill takes engineering time, the runbook needs review afterwards, and someone has to watch replication lag between drills.
In one example scenario, a dual-region build for a healthcare-adjacent Canadian SaaS, infrastructure cost rose 38% from running a second region. That build ran two independent regions for data residency, which is heavier than a warm standby, so the figure is not a typical result. The same example scenario reports that untangling single-region assumptions took longer than building the second region.
To estimate your own cost, list each data store, each system that assumes a single region, and the hours a drill would take. The article on how managed cloud hosting is priced explains how drivers like these become a quote.
Who should operate the disaster recovery setup?
An in-house team is the right operator when the company already has cloud engineers on call and runs drills on a calendar.
A DRaaS or managed infrastructure provider fits when nobody inside owns the runbook between incidents. Ask for the last drill report, and see the criteria to verify in a managed hosting provider.
A managed provider is the wrong choice when tested backups already meet your contractual RTO. It is also the wrong choice when the provider cannot operate on the cloud your workload already uses, or when your customers require a certification report the provider does not hold.
A disaster recovery checklist to take into a vendor call
- What RTO and RPO does the design target, and who on our side signs them off?
- Is replication synchronous or asynchronous, and which data trails?
- Is the standby sized for steady state or for peak load?
- Who decides to fail over, and is the cutover manual or automatic?
- When was the last real failover drill, and can we see the report?
- How do releases and secrets reach the standby?
- Where do the standby and the backups physically live?
- How do we fail back to the primary, and what does the agreement say about recovery?
A provider that answers all eight in writing has given you a recovery posture you can defend.
Where Stack Harbor fits
Stack Harbor is a Canadian-owned managed services provider (MSP) for production cloud environments, headquartered in Montréal. It serves SMBs and agencies that run production systems without a 24/7 operations team of their own.
Stack Harbor’s Multi-Region DR solution uses warm standby as its default design. Its published scope includes asynchronous database replication with lag monitored against the RPO, a written data-consistency model, and DNS failover with a manual-promote runbook gated by a human acknowledgement. A drill is scheduled every quarter, and the page describes it as a real end-to-end failover, not a tabletop. The RTO and RPO numbers are scoped in an assessment and signed off by a named owner on the client’s side. The assessment produces a one-page DR posture summary to hand to a buyer or an auditor, and the reviewer makes the determination.
The solution page describes the design as independent of the host: AWS, Virtuozzo or cPanel servers can carry it, so a workload on AWS can stay on AWS. Stack Harbor’s own Canadian infrastructure runs in two data centres in Montréal. On Cloud Compute, regional cutover is a managed operation, not an automatic one.
The service level agreement commits to 99.9% monthly availability for network and infrastructure as a service (IaaS), with a service credit as the remedy. It contains no RTO or RPO commitment. The Trust & Security page describes backup practices, including verified restore tests and a quarterly restore rehearsal where in scope. It also states that Stack Harbor holds no SOC 2 report of its own. Stack Harbor does not publish prices. A fixed quote follows an assessment, as described in how Stack Harbor scopes and prices work.
If tested backups meet your contractual RTO, keep them and keep testing them. If they do not, request a DR assessment and bring the clause that names your recovery objectives.
