VPS Backup Automation with rsync, restic, and rclone: Cron Jobs, Snapshots, and Offsite Copies

A misconfigured cron job or an accidental rm -rf can erase months of work in seconds, and provider-level storage failures, while rare, do happen. The 3-2-1 rule — three copies of your data, on two different media types, with one copy offsite — exists for exactly this reason, and on a VPS it is fully automatable with three complementary tools: rsync for continuous file-level sync, restic for encrypted, deduplicated snapshots, and rclone for offsite copies to object storage.

Storage sizing comes before the pipeline: a snapshot repository needs headroom above your live data, and offsite copies consume their own quota. If you are still choosing the server, see the full specs on our VPS comparison table and pick a plan with at least double your dataset size in disk.

The Tools and What Each One Does

Tool	Job	Key property
rsync	File-level sync over SSH	Incremental delta transfers
restic	Point-in-time snapshots	Encrypted, deduplicated, append-only
rclone	Offsite cloud copies	40+ backends: S3, B2, GCS, Drive

Each tool fills one slot in the pipeline. rsync mirrors directories; restic stores encrypted snapshots you can restore to any moment in time; rclone syncs the snapshot repository to cheap object storage so a total VPS loss still leaves you with a recoverable copy.

The pipeline is deliberately layered rather than redundant: rsync gives you a current, browseable copy, restic gives you history with encryption at rest, and rclone gives you geographic separation. If any single layer fails — a dead backup disk, a corrupted repository, a full cloud bucket — the other two still cover you. That layering is what turns a backup script into a backup strategy.

Before automating anything, decide what actually needs backing up. Web roots, upload directories, database dumps, and /etc configuration are the obvious candidates; package caches, session files, and build artifacts are not. If deleting it costs you more than an hour to rebuild, it belongs in the pipeline — that list becomes the --exclude/--include rules you maintain for years.

Installation on Ubuntu 24.04

apt update && apt install -y rsync restic rclone
restic self-update || true
rclone version   # confirm all three are present

All three tools live in the default Ubuntu repositories, so installation is a single command. restic also ships a self-update helper that keeps the binary current between OS releases.

rsync: Daily File-Level Sync

rsync -avz --delete /var/www/ backup@remote:/backups/www/ \
  --exclude cache/ --exclude tmp/

• -a preserves permissions, ownership, and timestamps; -vz gives progress and compression.
• --delete mirrors deletions so the copy never drifts from the source.
• --exclude keeps caches and temp files out of the backup, cutting both time and bandwidth.
• Run it over SSH with key-based auth — never a password, or cron will fail silently.

restic: Encrypted, Deduplicated Snapshots

export RESTIC_REPOSITORY=/backups/restic
export RESTIC_PASSWORD="$(cat /root/.restic-pass)"
restic init
restic backup /var/www /etc /var/lib/mysql --exclude /var/www/cache
restic forget --keep-daily 7 --keep-weekly 4 --prune

restic splits files into chunks and stores each chunk once, so a 10 GB site with daily changes of a few MB keeps the repository small. The repository is encrypted with your passphrase — store it in a password manager, because without it the snapshots are unrecoverable.

The forget --prune step stops the repository growing without bound: forget marks old snapshots for removal per your retention policy, and --prune reclaims the space. Without pruning, a busy site can balloon to several times its live size and quietly fill the VPS disk. Run restic snapshots periodically to confirm the retention policy — seven daily, four weekly snapshots is a sane default for most production sites.

rclone: Offsite Copies to Object Storage

rclone config          # interactive: pick S3, B2, GCS, or Drive
rclone sync /backups/restic offsite:vps-backups/ --checksum

Point rclone at the restic repository rather than the raw files: you replicate one encrypted, deduplicated blob instead of thousands of loose files, and the offsite copy stays consistent with the snapshot index.

One Cron Schedule to Rule Them All

30 2 * * * rsync -avz --delete /var/www/ backup@remote:/backups/www/
15 3 * * * /usr/local/bin/restic-backup.sh
45 4 * * * rclone sync /backups/restic offsite:vps-backups/ --checksum
0  6 * * 0 restic forget --keep-daily 7 --keep-weekly 4 --prune

Stagger the jobs so rsync finishes before restic snapshots the directories, and restic finishes before rclone replicates. Redirect output to a log and add MAILTO or a webhook so failures are visible, not silent.

Write the restic job as a small script instead of a one-liner so you can add error handling: set -euo pipefail, capture the exit code, and exit non-zero on failure so cron’s MAILTO fires. A backup that silently fails for three weeks is worse than no backup — you only discover it at the worst possible moment.

• Keep the backup logs in a dedicated file (/var/log/backup.log) with timestamps, and rotate them with logrotate so they do not grow forever.
• Add a simple health check: have the cron job write a timestamp file, and monitor its age — if it stops updating, something is broken.
• Test the restore procedure on a throwaway VPS, not the production box, so a mistake during testing cannot hurt live data.

Testing Restores Is the Real Backup

• Run restic restore latest --target /tmp/restore-test once a month and diff a few files against production.
• Test rsync with --dry-run to confirm the remote tree matches expectations.
• Verify the offsite copy with rclone check offsite:vps-backups/ — checksums, not just existence.
• Document your recovery time objective so you know how long a full restore is allowed to take.

Whatever toolchain you pick, schedule a restore test at least monthly — an untested backup is a guess, not a guarantee. If you are provisioning a second VPS purely as a backup target, compare plans side by side on our comparison table to find one with the disk and bandwidth this pipeline needs.

InterServer’s VPS plans include generous storage and unmetered bandwidth, which makes them a practical choice for an offsite backup node. Check InterServer VPS plans and pricing before you commit.