The 3-2-1 Backup Strategy: RPO and RTO for VPS

The cheapest backup is the one that quietly runs every night. The most expensive is the one you discover at 3 a.m. during an incident, only to find it has nothing you can restore. A backup strategy exists to close that gap, and two numbers define it before any tool does: RPO and RTO. Once those two numbers exist, the 3-2-1 rule stops being dogma and becomes a checklist you can size and schedule.

RPO and RTO define your target

Recovery Point Objective (RPO) is how much data loss your application tolerates, measured in time. An RPO of 24 hours means restoring to a copy that is at most one day old is acceptable. Recovery Time Objective (RTO) is how long the outage may last. An RTO of 4 hours means the service must be serving traffic again within four hours of the failure being declared.

These two numbers drive every downstream decision:

• RPO sets backup frequency and whether you need point-in-time recovery on top of nightly dumps.
• RTO sets the restore method and how much automation and practice you need. A restore that takes three hours by hand means your effective RTO is already three hours plus.
• RPO and RTO together set retention length, storage budget, and whether the off-site copy must be warm enough to pull from quickly.

If you have not written these down, take defensible defaults today: RPO 24 hours, RTO 4 hours. Most small applications live comfortably inside that box, and once you measure a real restore you will usually upgrade RPO to under an hour because it costs very little.

The 3-2-1 rule on a single VPS

Keep three copies of the data, on two different media types, with one copy off-site.

• Three copies: the live data plus two distinct backups, so losing any single copy still leaves you safe.
• Two media: local disk and remote object storage share neither a failure mode nor an attacker's path. SSD plus a far-away bucket is the classic pair.
• One off-site: the copy that survives disk failure, ransomware, or a problem at the facility hosting the live node. Netbay runs the production copy in Lucknow DC01; the off-site copy should live somewhere independent of it.

The numbers only matter as targets. A nightly dump at 02:00 satisfies a 24-hour RPO only if the previous night's copy is still good at 23:45. If the server dies the evening right after a dump, you fall back a full day. Tight RPO is served by more frequent dumps, or by snapshots with a short point-in-time recovery window layered on top.

Sizing the storage before you schedule

A nightly full dump with 30 days of retention stores roughly one copy of the database per day, compressed. For a 5 GB PostgreSQL database, plan for 150 to 250 GB of backup storage per month, and double it if you keep two full copies off-site. That is the real price of a working 3-2-1, and it is usually cheaper than one late-night hour of incident overtime.

Schedule to the RPO, not to habit:

• RPO 24 hours: one dump per night is fine.
• RPO 4 hours: dump every four hours, or snapshot a few times a day and dump once.
• RPO under 30 minutes: dumps plus continuous log shipping beats brute-force repetition.

A starting pipeline: dump, push off-site, check

A strategy is a pipeline, not a folder of .sql files. This script dumps, compresses, pushes a copy off-site, prunes by retention, and leaves a log line you can grep in the morning.

#!/usr/bin/env bash
# /usr/local/bin/streamback.sh
set -euo pipefail
DUMP_DIR=/var/backups/app
MIRROR=sftp:offsite:/backups/app
stamp=$(date +%F)
mkdir -p $DUMP_DIR
pg_dump "postgres://app_user@10.0.0.4/appdb"   | gzip -9 > $DUMP_DIR/appdb.$stamp.sql.gz
restic -r $MIRROR backup $DUMP_DIR >> $DUMP_DIR/backup.log 2>&1
restic -r $MIRROR forget --keep-daily 30 --prune >> $DUMP_DIR/backup.log 2>&1

Schedule it, and add a weekly restore drill so a broken pipeline cannot hide for a month:

# /etc/cron.d/streamback
30 2 * * * root /usr/local/bin/streamback.sh
0 5 * * 0  root /usr/local/bin/restore-drill.sh

Takeaway

RPO and RTO are the only two numbers that make a backup strategy defensible. Write them down, build the layout around them, and schedule the pipeline to match. When you need a staging box to practice restore drills, spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds from the dashboard or the API at netbayhosts.in.