How to Build a 3-2-1 Backup System on a Single VPS Budget

3-2-1 backup sounds like something only larger teams can afford. It is not.

For most VPS projects, the real problem is not cost. It is ambiguity. Teams think they have backups, but they have not tested restore paths or data integrity.

This guide gives you a practical 3-2-1 model for lean budgets.

First, define your critical data

Before tools, list data classes:

application database
user uploads and media
app configuration and secrets
deployment artifacts and IaC

Each class needs a backup method and a recovery target time.

Two targets keep the discussion concrete:

RPO (Recovery Point Objective): how much data you can lose (example: 15 minutes).
RTO (Recovery Time Objective): how long restore can take (example: 1 hour).

RPO drives backup cadence. RTO drives restore design (snapshots vs rebuild from backups).

A realistic 3-2-1 design for small teams

The model:

3 copies of data
2 different storage media or systems
1 offsite copy outside your primary provider account

Example architecture

Primary copy: live data on production VPS.
Secondary copy: daily snapshots in provider backup service.
Tertiary offsite copy: encrypted object storage in another provider or account.

This design is affordable and reduces single-account risk.

You can do this without paying for a second always-on VPS. Offsite object storage is usually the cheapest way to get the “1 offsite” copy.

Retention policy you can actually maintain

Use a layered retention plan:

daily backups: keep 7 days
weekly backups: keep 4 to 6 weeks
monthly backups: keep 6 to 12 months

Do not keep everything forever by default. Unlimited retention is usually unmanaged risk disguised as safety.

Backup integrity checks (non-negotiable)

Every backup job should include:

completion status
artifact checksum or hash
decrypt + restore-read test for at least one file (or a small DB dump)

If you cannot verify backup integrity, you are collecting expensive optimism.

Restore drills: the part most teams skip

Schedule one restore drill per month:

Restore backup into staging VPS.
Run app migrations and boot process.
Validate login flow, data access, and key endpoints.
Measure total restore time.

Track the measured restore time against your RTO target.

At least once per quarter, force a restore from the offsite copy (not only provider snapshots). This is where most “we have 3-2-1” claims fail.

A compact decision table

Use this table to choose backup frequency:

Workload type	Data change rate	Suggested DB backup cadence	Suggested file backup cadence
Marketing site	Low	Daily	Daily
SaaS app	Medium/High	Hourly incremental + daily full	Daily or every 6 hours
Ecommerce	High	Every 15-30 minutes incremental	Every 1-2 hours

Start conservative and tune after two months of evidence.

Security controls for backup pipelines

Backup systems often become your weakest point. Add these controls:

encrypt backups at rest and in transit
use separate credentials from production app credentials
restrict deletion permissions on backup buckets
enable bucket versioning or object lock (immutable backups) when available
alert on unusual backup deletion activity

If ransomware reaches production and backup with the same credentials, 3-2-1 collapses.

A one-page backup runbook

Document this in plain English:

where backups are stored
how to restore each data class
who approves recovery actions
how to rotate backup credentials

Keep this runbook versioned with your infrastructure code.

Final advice

Small VPS teams do not need complex backup platforms. They need tested recovery.

Build a simple 3-2-1 setup, verify it monthly, and your system will survive events that would otherwise become business-ending incidents.

Reference

3-2-1 backup strategy overview: Backblaze
Contingency planning and backup testing guidance (NIST SP 800-34r1): csrc.nist.gov

How to Build a 3-2-1 Backup System on a Single VPS Budget