Disaster Recovery Hosting: Run a Standby Server in a Second Region

Disaster recovery hosting means having a tested way to bring your service back in a different location when the primary server, or the whole data center it sits in, becomes unavailable. In practice that is three things: copies of your data stored somewhere else, a standby server in a second region that can take over, and a written procedure for switching traffic to it. How much of each you need is set by two numbers, RPO and RTO.

RPO and RTO in plain words

• RPO (recovery point objective) is how much data you can afford to lose, measured in time. An RPO of 24 hours means restoring yesterday's state is acceptable. An RPO of one minute means you need near-continuous replication.

• RTO (recovery time objective) is how long you can afford to be down. An RTO of a day allows you to build a new server from backups. An RTO of fifteen minutes means a standby must already be running.

Set both per system, not per company. A marketing site may tolerate a day of downtime and a day of lost edits; an order database usually cannot. Writing these numbers down first keeps the rest of the plan honest, because every step toward a smaller RPO or RTO costs money and operational effort.

Backups are not disaster recovery

Backups answer the question "can I get my data back?" Disaster recovery answers "how fast can I run again, somewhere else?" You need both, and they fail in different ways:

• A backup stored on the same server, or in the same facility, can disappear in the same incident as the server it protects.

• A backup you have never restored is a hope, not a plan. Restores of large databases can take far longer than people expect.

• Replication is not a backup. If someone drops a table on the primary, the replica drops it a moment later.

Start with a sound backup scheme, ideally the 3-2-1 approach described in our VPS backup strategy guide, then add a standby on top for the systems whose RTO a restore cannot meet.

Cold, warm and hot standby

Cold standby

No second server runs day to day. You keep backups and configuration off-site, and in a disaster you order or start a server in another region, install the stack and restore. It is the cheapest option. RTO is measured in hours, and RPO equals the age of your newest off-site backup.

Warm standby

A smaller server runs in the second region with the software installed and the database replicating continuously. On failover you promote the replica, scale up if needed, and point traffic at it. RTO is typically minutes to an hour, and RPO is close to the replication lag, often seconds. This is the sweet spot for most small and mid-sized businesses.

Hot standby

A full-size copy runs in the second region and can take traffic immediately, sometimes serving users all the time in an active-active setup. RTO and RPO can approach zero, but you pay for two production environments and take on real complexity: data conflicts, session handling and careful testing of every change in both places.

Why the standby belongs in a second country

A standby in the same building protects you from a failed disk or motherboard, not from a power event, an upstream network problem or a local incident that affects the whole facility. Putting it in a different country gives you independent power, independent networks and independent local risks.

Pick the pair by audience and by data rules:

• Cairo plus London suits MENA-focused services: Cairo as primary for Egyptian users, London as a well-connected fallback.

• Warsaw plus Berlin keeps both copies inside the EU, which simplifies data-location questions for EU-facing services. Location is only one part of GDPR compliance, so check your own obligations. Our guides to VPS hosting in Warsaw and VPS hosting in Germany cover each side.

• London plus Warsaw or Berlin works for European audiences spread across the UK and the mainland.

Distance matters for replication too. Across countries, keep replication asynchronous: synchronous replication makes every write wait for the far site to confirm, which adds the round trip to each transaction.

Database replication basics

For PostgreSQL, streaming replication is the standard approach. On the standby, clone the primary and let pg_basebackup write the replication settings for you:

# on the standby, with PostgreSQL stopped and an empty data directory
sudo -u postgres pg_basebackup -h PRIMARY_IP -U replicator \
  -D /var/lib/postgresql/16/main -R -X stream -P

The -R flag creates standby.signal and the connection settings, so the server starts as a read-only replica. The primary needs a replication user and an entry in pg_hba.conf that allows it only from the standby's IP. Restrict port 5432 in the firewall to that address, or run replication over a WireGuard tunnel.

Watch lag on the standby, because lag is your real RPO:

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

On failover, promote the standby with SELECT pg_promote();. Before you do, make sure the old primary cannot come back and accept writes on its own, or you end up with two databases that both think they are the primary. MySQL and MariaDB offer similar binary-log based replication with the same caveats.

Files, configuration and secrets

• Sync uploads and user files with rsync -az on a schedule, or use a backup tool such as restic that stores encrypted snapshots in the second region.

• Keep server setup in scripts or Docker Compose files under version control, so the standby is built the same way as the primary.

• Store secrets and environment files where the on-call person can reach them when the primary is gone.

• Plan TLS: copy certificates to the standby or make sure it can request new ones once DNS points at it.

• Disable scheduled jobs on the standby until it is promoted, so emails, invoices or syncs do not run twice.

DNS failover and TTL

Each server has its own dedicated IPv4 address, so failing over to another country usually means changing your DNS records to point at the standby. The record's TTL decides how long resolvers may keep serving the old address. Check it with:

dig +noall +answer example.com A

Lower the TTL of critical records to around 300 seconds well before you need it, because the old, longer TTL must expire first. Some resolvers hold records longer than asked, so expect a tail of traffic to reach the old IP for a while. Many DNS providers offer health-check based failover that switches records automatically. If your site sits behind a proxying CDN, switching the origin there takes effect without waiting on visitors' DNS caches.

Write the runbook, then test it

A runbook is a numbered list someone can follow at 3 a.m. under stress. Keep it short and specific:

1. Who decides to fail over, and how they are reached.

2. How to confirm the primary is really down rather than suffering a brief network blip.

3. How to fence the old primary (stop the database, block it in the firewall).

4. Exact commands to promote the database and start the application on the standby.

5. DNS or CDN changes, with the records and values written out.

6. Checks that prove the service works: login, a test order, background jobs, email.

7. How to fail back once the primary region is healthy, including resyncing data.

Then rehearse it on a schedule, for example every quarter and after major changes. Time each run: the measured duration is your real RTO, and the first rehearsal almost always finds a missing step.

Cost tradeoffs

• Cold: pay for off-site storage only; accept hours of downtime.

• Warm: pay for a smaller always-on server; accept a short, manual switchover.

• Hot: pay for two full environments plus engineering time; get near-instant failover.

Compare that cost with what an hour of downtime and a day of lost data cost your business. Uptime guarantees help too, but read what they cover: our explainer on what 99.9% uptime means shows why an SLA is compensation, not a recovery plan.

Frequently asked questions

Is a daily backup enough for disaster recovery?

Only if you can accept losing up to a day of data and the time it takes to rebuild and restore elsewhere. Store the backup in another location and test the restore to know your real recovery time.

Can the standby server be smaller than the primary?

Yes, for a warm standby. Size it to keep up with replication, and know in advance how you will scale it up on failover and how long that takes.

Should I use synchronous replication between countries?

Usually not. Every write would wait for a cross-border round trip. Asynchronous replication with lag monitoring is the common choice for a second region.

How often should I test failover?

At least a few times a year and after major infrastructure changes. An untested runbook tends to fail on the first real incident.

Building a two-region setup with IM HOST

IM HOST operates in five countries: Cairo, London, Warsaw, Berlin and New York, with current stock shown on the data centers page, so a primary and standby can sit in different countries with one provider. Cloud VPS includes free automatic backups every 72 hours, a useful extra copy alongside your own database dumps. Linux VPS gives full root on KVM and NVMe for building replication yourself, with daily backups available as an add-on.