Published: 23 September 2026
Most small teams have backups and no plan. The backups are real, the restore has never been rehearsed, and the recovery time objective on the wiki page is a number someone made up. A warm standby in a second country is the cheapest way to turn that number into something you have actually measured — and on hourly billing, the rehearsal costs less than the coffee you drink during it.
Cold, warm, hot — and what each one costs
The vocabulary gets used loosely, so let us pin it down in terms of what you pay for.
| Posture | What exists between incidents | Realistic recovery time | Standing cost |
|---|---|---|---|
| Cold | Backups in object storage. No server. | Hours — you are provisioning, restoring and configuring under pressure | Storage only |
| Warm | A small VPS in another country, configured, with data replicating or restored on a schedule | Minutes — start services, flip DNS | One small VPS |
| Hot | Full capacity running in both places, traffic balanced | Seconds, automatic | Double |
Hot is the right answer for a payment processor and the wrong answer for almost everyone else. Warm is the sweet spot: you carry one small machine, and the recovery is a runbook rather than an archaeology project.
What a warm standby costs on our grid
The standby does not need to match production. It needs to hold the data and be able to run degraded for a day. Against our VPS plans:
| Standby size | Bucharest | Warsaw / Amsterdam | Frankfurt / Vienna |
|---|---|---|---|
| 2 GB / 1 vCPU / 20 GB | €4.00 | €5.00 | €5.50 |
| 4 GB / 2 vCPU / 40 GB | €6.00 | €8.00 | €9.00 |
| 8 GB / 2 vCPU / 60 GB | €10.00 | €14.00 | €16.00 |
| 16 GB / 4 vCPU / 80 GB | €16.00 | €24.00 | €26.00 |
Per month, euro, before VAT. A 4 GB standby in Bucharest for a production stack running in Frankfurt is €6.00 a month — genuinely less than most teams spend on the monitoring that would tell them production is down.
Because the two sites are in different countries, a single-datacentre event does not take both. That is the whole point of paying the extra six euro.
Picking the second country
Our VPS pool spans five countries: Romania, Poland, the Netherlands, Germany and Austria. Choose the pair to maximise independence without making replication painful.
- Frankfurt primary → Bucharest standby. Different country, different power grid, different transit mix, and the cheapest standby on the grid.
- Amsterdam primary → Warsaw standby. Same price tier, a clean east–west split.
- Vienna primary → Bucharest or Warsaw standby. Short paths, so replication lag stays small.
- Bucharest primary → Frankfurt standby. If the failover case you fear is regional connectivity rather than a single facility, put the standby on the deepest-peered side.
Latency between the sites matters for synchronous replication and matters much less for the asynchronous kind, which is what a warm standby should be using. The full price grid across all five is in our location pricing post, and each location page lists approximate round trips to nearby hubs.
Building it
1. Replicate the data continuously, not nightly
A nightly copy means your recovery point objective is up to 24 hours of lost work. For a relational database, use its own replication — a streaming replica on the standby is the single highest-value piece of this design. For files, a scheduled sync every few minutes gets you close enough. Keep the standby's copy read-only until failover so nothing writes to it by accident.
2. Configure the standby exactly like production, and prove it
Same configuration management, same package versions, same TLS certificates. The failure mode of every warm standby is discovering, during an incident, that it is three versions behind and missing an environment variable. If you deploy with a pipeline, have the pipeline deploy to the standby too.
3. Keep the DNS TTL short before you need it
A five-minute TTL on the records you will flip costs nothing in normal operation and is the difference between a five-minute and a two-hour recovery. Decide in advance which records move, and write the values down in the runbook rather than deriving them at three in the morning. If you want the DNS layer itself to be redundant, we covered that in building a redundant multi-location DNS setup.
4. Write a runbook a tired person can follow
Numbered steps. Exact commands. No judgement calls. It should cover: promote the database replica, start the application services, flip DNS, verify, and — crucially — how to fail back afterwards without losing the writes that happened while you were failed over.
5. Rehearse it, and let the rehearsal be cheap
This is where hourly billing earns its place. Bring up a third machine — a scratch copy of production — run the failover procedure against it, time yourself, throw it away. A 16 GB machine in Bucharest is €0.0222 an hour, so a two-hour rehearsal is four and a half cents. There is no budget argument against doing that quarterly.
The billing facts you need to plan around
- The standby should be on the monthly cycle, not hourly. It runs continuously, so the monthly price is the right instrument. Hourly is for the rehearsal machines and the temporary extra capacity you bring up during an incident.
- A stopped VPS still bills. A powered-off virtual machine keeps its RAM allocation, its disk and its IP on the node, so it costs the same as a running one. You cannot save money by parking the standby powered-off — and you would not want to, because a standby that has not booted in six weeks is not a standby.
- Hourly draws on prepaid credit, once per clock hour at the top of the hour, UTC. Keep enough credit that an incident-day burst does not trip a suspension — there is one hour of grace after credit runs out and 48 hours before termination, and you do not want to spend either of those windows on a payment page.
- Annual is 10% under twelve months at the base rate if the standby is clearly permanent.
Where a VPS standby stops being enough
If production is a dedicated server saturating real hardware, a 4 GB standby will hold your data but will not carry your traffic. That is still worth having — data intact and a degraded service beats an outage — but be honest in the runbook about what "recovered" means. And the standby is not a backup: it replicates your mistakes as fast as it replicates your data. Keep real, versioned, off-site backups underneath it. We wrote about that side in automated off-site backups.
Start with the cheap version
Order a 4 GB VPS in a country that is not the one production sits in, set up replication, and write a one-page runbook. That is €6.00 a month in Bucharest. Then book two hours next quarter, spin up a scratch machine on the hourly plans, and find out whether the runbook is true.