When evaluating disaster recovery: DR site on cloud vs secondary VPS, cloud DR usually wins when you need low RTO/RPO. It also suits elastic failover capacity and protection beyond one host.
Set RTO and RPO before choosing a recovery site
Your recovery time objective (RTO) is the longest users can lack a working service. Your recovery point objective (RPO) is the most data you can lose.
Recovery targets that point to cloud DR
Cloud disaster recovery can support a 15-minute to 2-hour RTO. The result depends on the design.
A hot or ready cloud setup may reach the lower end. Warm-site and pilot-light designs usually need 30 minutes or more.
Cloud DR also fits services with more than two linked servers.
Amazon Web Services, Microsoft Azure, and Google Cloud can keep replica data in another region. They can then start compute capacity, load balancers, and database services during an outage.
Recovery targets that fit a secondary VPS
Use this threshold: Choose cloud DR when an outage beyond 2 hours creates material revenue, contract, or safety risk. Choose a secondary VPS only when tested capacity serves priority traffic. Its RTO should be measured in hours, not minutes.
Choose a recovery site by scoring the workload. Do not compare monthly server prices alone.
A single app with under 100 GB can often use a secondary VPS. It needs predictable traffic, a four-hour RTO, and a 24-hour RPO.
It also needs tested restore steps. A three-tier app with several databases needs more robust recovery infrastructure.
An app with 2 TB of changing data and payment flows usually needs cloud DR. This is also true when its RTO is below one hour.
That design needs cross-region replication and automated capacity.
Budget must include outage cost. If one hour of lost orders costs more than standby infrastructure, favor recovery speed over price.
Also score provider outage exposure and shared failure risk. A cheap standby can fail with the primary.
A secondary VPS is cheaper, but may share failure risk
A secondary VPS can cost less. It works only when it can recover the service independently and carry failover traffic.
| Recovery design | Typical standby cost | Tested RTO range | Main failure risk | Best fit |
|---|
| Same-provider VPS replica | $12 to $40/month, plus backups | 2 to 12 hours | Provider, control-plane, or regional outage | Low-risk internal tools |
| Different-provider VPS warm site | $25 to $100/month, plus transfer | 1 to 6 hours | Fixed capacity under peak load | One or two stable apps |
| Cloud warm site, cross-region | $50 to $250/month before activation | 30 minutes to 2 hours | Untested dependencies or cost surge | Revenue-facing multi-service apps |
| Cloud pilot-light DR | $20 to $150/month, then $100 to $1,000+/day in failover | 1 to 8 hours | Slow capacity build or missing automation | Variable traffic and tight budgets |
Shared failures defeat a cheap standby
A DigitalOcean, Linode, Vultr, or Hetzner VPS can be a sound warm site. The primary must be elsewhere.
Two servers in one provider and region share risk. This includes two machines in one US East location.
A provider-wide network event can affect both servers. An account lockout or API outage can also affect both.
Capacity matters during a real outage
A 2 GB VPS may pass health checks. It may fail when all production traffic arrives.
Test with a representative load. Include database reads, background jobs, cache misses, uploads, and outbound email.
If the warm site handles only 30% of demand, document features to disable.
Failover path to test, not just describe
Primary fails→Freeze writes→Promote replica→Switch DNS or load balancer→Validate user transaction
A successful test includes failback. Sync changed data, switch traffic back, and confirm that no records were lost.
Choose a secondary VPS if your workload is small and steady. It must tolerate a tested recovery window of at least one hour.
A backup, replication, high availability, and disaster recovery solve different problems. Backups preserve copies of data that you can recover.
Replication copies data to another system. It can also copy corruption, accidental deletion, or ransomware.
Retention settings can limit that risk. High availability keeps a service running through local failures.
Those failures include one VM or availability zone failing. It may not protect against a regional or provider-wide event.
Disaster recovery joins protected data with runnable infrastructure. It also needs traffic routing, access credentials, dependencies, and a tested recovery process.
One secondary VPS is not always DR. It remains a single failure point without tested restores or enough traffic capacity.
It also fails the test if it shares the provider or region. Skipping DR tests creates similar risk.
Cloud DR earns its cost when failover traffic can spike
Cloud DR is worth its higher operating cost when the backup site must absorb uncertain traffic. It also suits services with many linked parts.
It can help survive a regional outage. A VPS often cannot meet that need.
Costs that appear only after activation
Total ownership cost includes replicated block storage and snapshots. It also includes cross-region transfer, egress, public IPs, and load balancing.
Monitoring, support, licenses, and staff testing time also add cost. These items are often overlooked until planning or failover.
AWS outbound internet transfer commonly costs about $0.09 per GB after included allowances. Two TB of emergency traffic can add about $180 before other services.
Practical recovery architectures
Three practical patterns cover most workloads. Each pattern trades monthly cost against recovery time.
A VPS replica design runs a database replica and a small app stack. It should run on a secondary VPS at another provider.
During an incident, promote the database and redirect traffic. This design fits one or two stable apps.
Cloud DR can use a warm site with services already available. It can also use pilot-light DR.
Pilot-light DR keeps data, images, and infrastructure-as-code ready. Compute capacity starts only after failover.
A hot site has enough live capacity for near-immediate cutover. A cold site may hold only backups and deployment definitions.
A cold site has a much longer RTO. It saves money but asks more of your recovery team.
A hybrid design can keep a VPS warm site for essential functions. It can use cloud resources for burst capacity, managed databases, or regional recovery.
Choose cloud DR if traffic can spike or dependencies must start together. Avoid it if your team cannot test automation and control failover costs.
Failover without failback leaves recovery unfinished
A DR plan is incomplete until it covers failover, validation, and failback. Put all three steps in the same runbook.
Run the recovery sequence in order
- Declare the incident. Freeze nonessential writes and record the last confirmed replication point.
- Confirm that the replica is consistent. Then promote the database or restore the approved point-in-time copy.
- Start app services, private networking, firewall rules, TLS certificates, secrets, queues, and mail delivery.
- Switch DNS failover or load-balancer routing. Account for DNS TTL values between 60 and 300 seconds.
- Validate a real user path. Check login, data writes, payment or key API calls, logs, and monitoring alerts.
- After repair, copy DR-side changes back. Test the primary and switch traffic back under change control.
Test the plan before a customer does
Run a planned DR test every 6 to 12 months. Test again after major DNS, identity, database, or network changes.
Check data consistency, user access, and traffic routing. Record the actual time needed.
ISO 22301 and NIST guidance treat tested procedures as part of continuity. Testing is not paperwork.
This comparison has limited value when the app is not critical. It also has limited value when it holds no valuable data. Use backups when they can restore service within a wide RTO. This does not replace high availability for brief local failures. Build documented backups, monitoring, and access recovery first. Then choose DR. HIPAA, PCI DSS, and similar duties may need controls beyond either design.
Frequently asked questions
Is a cloud DR site worth it for a startup?
Yes, if a two-hour outage costs more than cloud standby and testing. It also fits apps with several dependent services.
A secondary VPS is usually enough for one predictable service. That service must tolerate 4 to 12 hours of downtime.
Can a secondary VPS meet a 15-minute RPO?
Yes, asynchronous database replication can meet a 15-minute RPO. You must monitor and test replication lag.
It does not guarantee a 15-minute RTO. DNS, app startup, and capacity can take longer.
What is the hidden cost of cloud DR?
The largest surprise is activated usage during an outage. Compute, managed databases, load balancing, and egress can cost hundreds per day.
A $50 to $250 standby month can change quickly. Model 24, 72, and 168 hours of failover.
Does a backup count as disaster recovery?
No, a backup protects historical data. It does not prove that service returns within your RTO.
A DR design also needs runnable infrastructure and traffic routing. It needs credentials, dependencies, and a tested runbook.
Learn more
Here are some additional resources on this subject:
