VPS Backup Strategy: Rsync vs BorgBackup vs Rclone for Automated Server Snapshots

Losing server data is not a matter of “if” but “when.” Disk failures, accidental deletions, software bugs, and security breaches all threaten your VPS data. A solid backup strategy is the difference between a minor inconvenience and a catastrophic loss. This guide compares three powerful open-source backup tools — Rsync, BorgBackup, and Rclone — and shows you how to set up automated backups on any Linux VPS. No matter which tool you choose, finding a reliable VPS provider with good storage options is the first step.

What Makes a Good VPS Backup Strategy?

Before comparing tools, establish your backup requirements:

• Recovery Point Objective (RPO): How much data can you afford to lose? Measured in time — hourly, daily, weekly.
• Recovery Time Objective (RTO): How long can you afford to be down while restoring?
• 3-2-1 Rule: Three copies of your data, on two different media types, with one copy off-site.
• Encryption: Backups must be encrypted, especially if stored off-site or on cloud storage.
• Automation: Backups must run without human intervention. If you have to remember to run them, they will not get done.

Each tool below addresses these requirements differently. The right choice depends on your VPS resources, backup destinations, and recovery speed needs.

Rsync: The Universal File Synchronizer

Rsync is the oldest and most widely used tool in this comparison. It synchronizes files and directories between two locations using a delta-transfer algorithm that only sends differences.

How It Works

Rsync compares files by size and modification time (or checksum with the -c flag) and transfers only the changed blocks. It can operate locally, over SSH, or via an rsync daemon. Combined with hard links (--link-dest), it creates incremental snapshots efficiently.

Setup: Automated Daily Backups with Hard Link Snapshots

#!/bin/bash
# /usr/local/bin/backup-rsync.sh

SOURCE="/var/www /etc /home"
DEST_BASE="/backup/daily"
DATE=$(date +%Y%m%d)
LATEST=$(ls -1d "$DEST_BASE"/*/ 2>/dev/null | tail -1)

mkdir -p "$DEST_BASE/$DATE"

rsync -aP --delete --link-dest="$LATEST" $SOURCE "$DEST_BASE/$DATE/"

# Keep last 7 daily backups
find "$DEST_BASE" -maxdepth 1 -type d -ctime +7 -exec rm -rf {} \;

Pros and Cons

• Pros: Simple, pre-installed on most Linux distributions, works over SSH, extremely fast for small changes.
• Cons: No built-in encryption (relies on SSH), no compression, no deduplication across files — each snapshot is a full copy with hard links.
• Resource usage: Low CPU, moderate RAM for large directory listings. Storage grows linearly with changed files.

BorgBackup: Deduplication-Focused Backup Tool

BorgBackup (formerly Borg) is a modern backup tool with built-in deduplication, compression, and encryption. It splits data into chunks and stores each chunk only once, regardless of how many backup snapshots contain it.

How It Works

Borg creates repositories that store compressed, encrypted chunks of your files. When you create a new backup, Borg checks each file chunk against its repository — unchanged chunks are skipped (deduplication). This means your first backup is full-size, but subsequent backups only add genuinely new data. A 50 GB dataset with 500 MB of daily changes will grow by only ~500 MB per day after the initial backup.

Setup: Encrypted Automated Backups

#!/bin/bash
# /usr/local/bin/backup-borg.sh

export BORG_REPO="/backup/borg-repo"
export BORG_PASSPHRASE="your-strong-passphrase-here"

# Initialize repository (first run only)
# borg init --encryption repokey-blake2 "$BORG_REPO"

# Create backup
borg create --verbose --list --stats --show-rc \
    --compression lz4 \
    --exclude-caches \
    --exclude '/var/cache/*' \
    --exclude '/var/tmp/*' \
    ::{now:%Y-%m-%d_%H:%M} \
    /var/www /etc /home

# Prune old backups: keep 7 daily, 4 weekly, 6 monthly
borg prune --verbose --list --show-rc \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Pros and Cons

• Pros: Built-in deduplication (huge disk savings), compression (lz4 is fast, zstd for better ratios), authenticated encryption, append-only mode for ransomware protection.
• Cons: Slightly more complex setup, requires Borg installed on both source and destination (though remote repos work via SSH), restore speed can be slower due to chunk reassembly.
• Resource usage: Moderate CPU for compression, RAM proportional to chunk cache size (usually 100–500 MB). Disk usage grows slowly thanks to deduplication.

Rclone: The Cloud Storage Swiss Army Knife

Rclone is designed for syncing files to and from cloud storage providers: AWS S3, Google Drive, Backblaze B2, Dropbox, and 40+ others. It supports server-side copy where the cloud provider supports it, dramatically reducing bandwidth usage and time.

How It Works

Rclone uses a unified API across cloud providers. It can sync (one-way mirror), copy, or move files. With the --crypt remote feature, it encrypts files before upload, ensuring only you can read your backups. Rclone’s bisync mode enables bidirectional synchronization.

Setup: Encrypted Off-Site Backup to Backblaze B2

#!/bin/bash
# /usr/local/bin/backup-rclone.sh

# Sync /var/www to Backblaze B2 with encryption
rclone sync /var/www mycrypt:bucket/vps-backups/www \
    --verbose --progress \
    --backup-dir mycrypt:bucket/vps-backups/archive/$(date +%Y%m%d) \
    --delete-excluded

# Or use borg backup and then sync the repo
# borg create ... && rclone sync /backup/borg-repo mycrypt:bucket/borg-repo

Pros and Cons

• Pros: 40+ cloud provider support, built-in client-side encryption, server-side copy for low-bandwidth operations, very fast for initial syncs to nearby data centers.
• Cons: No deduplication (each backup is a separate copy unless using cloud versioning), no compression (though cloud storage is cheap), cloud egress costs for restore.
• Resource usage: Low CPU, moderate bandwidth. Storage cost depends on cloud provider (Backblaze B2 is ~$6/TB/month).

Head-to-Head Comparison

Feature	Rsync	BorgBackup	Rclone
Deduplication	No (hard links for snapshot sharing)	Yes (chunk-level)	No
Compression	No (can pipe through gzip)	Yes (lz4, zstd, zlib)	No
Encryption	Via SSH tunnel	Built-in (AEAD)	Built-in (crypt remote)
Cloud storage	Manual (ssh to cloud VM)	Via SSH to remote server	Native (40+ providers)
First backup of 50 GB	5–15 minutes (local)	10–30 minutes (with compression)	2–10 minutes (server-side)
Incremental of 500 MB	30 seconds	2–5 minutes	10 sec–2 min
Restore full backup	Fast (direct file copy)	Moderate (chunk reassembly)	Fast (direct file copy)
Learning curve	Low	Moderate	Low–Moderate

Recommended Backup Strategy by VPS Size

Budget VPS (1-2 GB RAM, limited disk)

Use BorgBackup locally with compression and deduplication. Store the repository on the same VPS if you have spare disk, then use Rclone to sync the Borg repository to Backblaze B2 or another cheap cloud provider once daily. This gives you local+offsite with minimal disk usage thanks to Borg’s deduplication.

# Combined approach for budget VPS
# 1. Borg creates deduplicated local backup
borg create /backup/borg-repo::{now} /var/www /etc
# 2. Rclone syncs Borg repo to cloud
rclone sync /backup/borg-repo remote:bucket/borg-repo

Mid-Range VPS (4-8 GB RAM, SSD storage)

Use BorgBackup with a higher compression level (zstd, level 8–12) and keep more retention (30 daily, 12 weekly, 12 monthly). Use Rclone for off-site replication. Consider InterServer VPS plans for affordable storage options suitable for backup repositories.

High-End VPS (16 GB+ RAM, large datasets)

Use Rsync with hard link snapshots for quick restores, plus Rclone for off-site archival. If you have databases, add a pre-backup hook that dumps all databases to flat files before the backup runs.

Automating Backups with systemd Timers

Instead of cron, use systemd timers for better logging and dependency management:

# /etc/systemd/system/vps-backup.service
[Unit]
Description=VPS Backup Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-borg.sh

# /etc/systemd/system/vps-backup.timer
[Unit]
Description=Run VPS backup daily at 3 AM

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=1800

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now vps-backup.timer

The RandomizedDelaySec=1800 spreads backups across a 30-minute window to avoid thundering herd issues on shared storage. The Persistent=true flag ensures missed backups run immediately after the server comes back up.

Testing Your Backups: The Most Overlooked Step

A backup you have never tested is not a backup — it is a wish. Schedule monthly restore tests:

#!/bin/bash
# /usr/local/bin/test-restore.sh - Run this monthly

# Test Borg backup integrity
borg check /backup/borg-repo

# Test restore to a temporary directory
mkdir -p /tmp/restore-test
borg extract /backup/borg-repo::latest --stdout | tar -t | head -20

# For Rsync: verify file count matches
rsync -avn --delete /var/www/ /backup/rsync-test/ | wc -l

# For Rclone: check remote listing
rclone ls remote:bucket/vps-backups --max-depth 3

Automate test restores to a separate directory or a staging VPS. If you use a Cloudways managed VPS, their built-in backup system can complement your own Borg or Rsync strategy for an extra layer of protection.

Conclusion

Your VPS backup strategy does not need to be complex to be effective. For most users, we recommend BorgBackup for local deduplicated backups combined with Rclone for encrypted off-site replication to cheap cloud storage. Rsync remains a solid choice for simple file-level backups where deduplication is not critical. Whichever tool you choose, follow the 3-2-1 rule, automate with systemd timers, and — most importantly — test your restores regularly. Compare VPS providers to find a hosting plan with enough storage to support your backup strategy.