You Don't Need S3 to Back Up Your Home Server or Production Server

Most backup guides assume you're on AWS with a fat budget. This one doesn't.

If you're running a small production server — a VPS, a homelab that serves real users, a side project with actual data — you can build a solid, layered backup system with tools you already have. No S3, no paid services, no complexity you don't understand.

pg_dump, rsync and rclone

Setup: I have 3 VM's setup inside my bare metal server.

Here's the strategy I use across a Proxmox setup on baremetal HP server. The same pattern applies to any Linux server.

The Three-Layer Strategy

Good backups have three properties: they're automated, layered, and offsite. This setup delivers all three.

PostgreSQL databases
        ↓ pg_dump,pgdump_all (compressed) + rsync for files
  Local SSD
        ↓ rclone copy
    Google Drive

Layer 1 — Database dumps to local SSD pg_dump with the -Fc flag produces compressed, restorable snapshots. A companion pg_dumpall --globals-only captures users, roles, and permissions that pg_dump misses. Both land on an attached SSD.

Layer 2 — File sync to SSD via rsync Application uploads and user files are rsync'd from the app server to the database server's SSD mount. The --delete flag keeps the destination clean — no stale files accumulating over time.

Layer 3 — Offsite via rclone to Google Drive rclone copy pushes everything to Google Drive. This is your disaster recovery layer — if the physical machine dies, your data is still there.

The Tools

pg_dump -Fc — PostgreSQL's native backup tool. The custom format (-Fc) is compressed binary, supports selective table-level restores via pg_restore, and is faster than plain SQL dumps for large databases.

rsync -avz --delete — The gold standard for incremental file sync over SSH. Archive mode, compressed transfer, with automatic cleanup of deleted files.

rclone — Think of it as rsync for cloud storage. Supports 50+ backends. Set it up once with rclone config, authenticate via OAuth, and it works like any other file operation.

cron — The legend that made it all possible.

The Architecture

What You Need

Component	Tool	Why
Database backups	pg_dump + pg_dumpall	Complete snapshots including globals
File sync	rsync	Incremental, SSH-native, battle-tested
Cloud offsite	rclone + Google Drive	Free 15 GB, expandable, zero setup cost
Scheduling	cron	Native to every Linux distro
Retention	Shell variable RETENTION_DAYS=35	Automatic cleanup, ~2 months of history
Network	Tailscale (optional)	Zero-config VPN between nodes

---

Setting Up rclone in 3 Steps

# 1. Install
curl https://rclone.org/install.sh | sudo bash

# 2. Configure (interactive, browser-based OAuth)
rclone config

# 3. Test
rclone ls googledrive:   # list your Google Drive root

The colon after googdrive is not a typo — it tells rclone you're referring to the remote, not a local path named googdrive.

---

The Cron Schedule

# On VM3 (database server) — as postgres user
X X X * *   /usr/local/bin/pg-backup.sh

# On VM1 (gateway) — as root
X X X * *   /usr/local/bin/send-ssd-backup.sh >> /var/log/backup.log 2>&1

X X X * *   /usr/local/bin/gdrive-backup.sh

---

One Thing Most Guides Skip

A backup you've never restored is a bet, not a guarantee.

After setting this up, run a restore drill. Spin up a throwaway VM, pull a dump from Drive, and run:

pg_restore -d mydb /path/to/backup.dump
and
create scripts for your files/folders backup

If it works, you have a backup system. If it doesn't, you have a false sense of security. Test early.

---

What This Costs

Resource	Cost
Google Drive (15 GB)	Free
rclone	Free / open source
rsync	Pre-installed
Tailscale	Free
Your time	learning + implementation ( X days)

The only real cost is the SSD — which you probably already have attached to your server or USB.

---

full guide on: https://gaurablearn.hashnode.dev/