DR for a Single Datacenter: RPO and RTO Plans

Disaster recovery for a fleet that lives in one datacenter is not a multi-region fairy tale. Netbay origin is Lucknow (DC01). That is a fact you design around, not a footnote. RPO is how much data you can lose. RTO is how long you can be down. Both are numbers you pick before the disk dies, not slogans you write after. A single building means a site-level event takes the public IPs with it. Hardware failure of one node is a different class of event and is the one you can actually absorb with a replica VPS sitting a few racks away in the same facility.

Name the Failures Before the Numbers

Write three rows, not one:

• Node death: one VPS is gone, the datacenter is fine. Target RTO in minutes if DNS or a floating workflow is ready; RPO is last replica apply or last snapshot.
• Disk corruption: the node boots but Postgres will not. RPO is last verified backup. RTO is restore time onto a new volume, which is a function of High-Speed SSD size and your restore command, not hope.
• Site unavailability: Lucknow is unreachable from the internet. RTO is however long it takes you to stand up a copy somewhere you already stored data. If you never copied data off-site, RPO is everything.

Teams collapse these into "we have snapshots" and then discover snapshots lived on the same node. A snapshot that is not copied off the failing unit is not a DR artifact. It is a convenience for rollback.

# Daily logical dump on the database node, then copy off the node
pg_dump -Fc -f /var/backups/app.dump app
sha256sum /var/backups/app.dump > /var/backups/app.dump.sha256

# Push to a machine you control that is not this VPS
rsync -az --chmod=600 /var/backups/app.dump* backup-offsite:/srv/app-backups/$(date +%F)/

The offsite destination is yours: an office NAS, a second provider you chose, a colleague's VPS in another city. It is not a hidden Netbay region. Do not invent one.

Replica in the Same Datacenter

A streaming replica on a second VPS in DC01 covers node death and many disk events. It does not cover a site event. Promote it when the primary is gone, point the app at the new address, and treat the old primary as tainted until you know why it died. Keep the replica on a separate node with its own High-Speed SSD. Sharing a disk with the primary is theatre.

# /etc/postgresql/16/main/postgresql.conf on primary
wal_level = replica
max_wal_senders = 4
archive_mode = on
archive_command = 'test ! -f /var/lib/postgresql/wal/%f && cp %p /var/lib/postgresql/wal/%f'

# recovery on the replica (postgresql.auto.conf)
primary_conninfo = 'host=10.0.0.20 user=replicator'
hot_standby = on

Measure apply lag. A replica that is 40 minutes behind is an RPO of 40 minutes, regardless of what the wiki says. Alert on lag, not on whether the postgres process exists. L3/L4 DDoS on the public API does not keep WAL flowing if you filled the primary disk.

RPO and RTO Are Budgets

Pick numbers you can fund. An RPO of zero means synchronous commit to a replica, which costs latency on every write. An RPO of 15 minutes means a 15-minute dump or WAL archive cycle and a replica you watch. An RTO of 30 minutes means a documented promote, a DNS TTL that is not 24 hours, and a runbook a second engineer can follow. An RTO of "soon" is not a number.

DNS is part of RTO. If the A record TTL is 3600, you have added up to an hour before clients find the promoted node. Lower TTL before you need it. Keep a spare VPS sized to production, powered off or on a cheap plan, so you are not waiting on provisioning during the only hour it matters. Pay-as-you-go INR billing makes a warm spare cheaper than a heroic rebuild.

Restore Is the Product

Untested backups are rumours. Once a month, provision a throwaway VPS, restore the latest dump, run the app against it, and time the whole path. That duration is your RTO. If it is four hours and you promised 30 minutes, either change the promise or change the procedure: smaller dumps, parallel restore, or a replica already warm. Application secrets, TLS keys, and nginx maps must be in the runbook or the restored node will boot and still be closed.

Takeaway

Single-datacenter DR is honest about site risk and ruthless about node risk. Replica for hardware, offsite copies you control for the building, and a timed restore for the number you print in the status page. Lucknow is the origin. Design as if that sentence is true, because it is.

Keep a warm spare and a replica on separate Netbay VPS nodes in Lucknow (DC01) and time a restore on a disposable box before you quote RTO to anyone — netbayhosts.in.