Rsync vs Rclone for Server Backups

By Kokil Thapa | Last reviewed: September 2026

Choosing between Rsync vs Rclone for server backups is a decision every operator hits after the first disk failure scare. Rsync is the classic Unix delta copier over SSH. Rclone speaks to S3, Google Drive, Backblaze B2, and dozens of other remote APIs. On production Linux system administration work, both tools show up constantly. This guide compares them on real criteria—incremental sync, encryption, restore speed, and cron automation—so you can pick one or combine both without guessing.

What Is the Difference Between Rsync and Rclone for Server Backups?

Rsync copies files by comparing checksums and sending only changed blocks. It expects a remote shell or daemon on the other side. Rclone treats remote storage as a filesystem and handles authentication, multipart uploads, and provider quirks for you.

Think of Rsync as a precision forklift between two warehouses you control. Rclone is the logistics broker that ships pallets to AWS, Wasabi, or Google Cloud without you writing SDK code.

On sister sites I maintain with Deployer 7 and GitLab CI—legal-tech portals like Notary Kathmandu—Rsync pushes nightly file snapshots to a secondary VPS. Rclone then mirrors encrypted archives to object storage. Neither tool replaces database dumps; they complement them.

The official Rsync project documentation covers delta-transfer mechanics. For Rclone, the Rclone docs list every supported backend and flag.

When Should You Use Rsync for Server Backups?

Rsync wins when both ends are Linux servers you administer. You already have SSH keys. You want hard-link snapshots that consume minimal extra disk. You need a restore in minutes, not hours of cloud download.

Install and test Rsync on Ubuntu

Rsync ships with Ubuntu. Verify with:

rsync --version
ssh -V

One-off directory sync over SSH

This copies your Laravel storage/ and uploaded media to a backup host:

rsync -avz --delete \
  -e "ssh -i /root/.ssh/backup_key -p 22" \
  /var/www/myapp/storage/ \
  backup@203.0.113.50:/backups/myapp/storage/

Flag breakdown:

• -a preserves permissions, symlinks, timestamps.
• -v prints transferred files—useful in cron logs.
• -z compresses during transfer on slow links.
• --delete removes files on the destination that no longer exist on source.

Hard-link snapshots with Rsync

Hard links let you keep daily snapshots without duplicating unchanged files. I've used this pattern on production Laravel applications for years:

BACKUP_ROOT="/backups/myapp"
SNAP="$BACKUP_ROOT/$(date +%Y-%m-%d)"
LATEST="$BACKUP_ROOT/latest"

mkdir -p "$SNAP"
rsync -av --delete \
  --link-dest="$LATEST" \
  /var/www/myapp/ \
  "$SNAP/"

rm -f "$LATEST"
ln -s "$SNAP" "$LATEST"

Each day creates a full directory tree. Unchanged files share inode blocks with the previous snapshot. Disk usage grows only with actual changes. See the dedicated walkthrough in automate server backups with Rsync and cron for a complete script.

Cron entry for automated Rsync

0 2 * * * /usr/local/bin/backup-rsync.sh >> /var/log/backup-rsync.log 2>&1

Pair this with MySQL binary logs for replication and backup if you need point-in-time database recovery. Rsync alone does not guarantee database consistency unless you dump first or use filesystem snapshots.

When Should You Use Rclone for Server Backups?

Rclone is the right call when your backup destination lives in the cloud. AWS S3, Wasabi, Backblaze B2, Google Drive, and even another provider's SFTP endpoint all work through one CLI.

I reach for Rclone when a client wants off-site protection without maintaining a second VPS. A Kathmandu business running a single EC2 instance often cannot afford hot standby hardware. Rs 1,500/month (~USD 11) on B2 beats Rs 3,500/month (~USD 26) for a duplicate server that sits idle.

Install Rclone on Ubuntu

curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip
unzip rclone-current-linux-amd64.zip
cd rclone-*-linux-amd64
sudo cp rclone /usr/local/bin/
sudo chmod 755 /usr/local/bin/rclone
rclone version

Configure a remote backend

Interactive setup creates a named remote in ~/.config/rclone/rclone.conf:

rclone config

For S3-compatible storage, choose s3, enter access key, secret, region, and bucket. Test connectivity:

rclone lsd myremote:

Sync backup archives to cloud

After your local script dumps the database and tarballs the site, push to cloud:

rclone sync /backups/daily/ myremote:mybucket/server-backups/ \
  --transfers 4 \
  --checkers 8 \
  --retries 3 \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO

Use copy instead of sync if you never want Rclone to delete remote files. Use sync when the remote should mirror local retention policy exactly.

For client-side encryption before upload, add a crypt remote wrapper. Your cloud provider sees only encrypted blobs. Generate a strong passphrase with a password generator and store it in your secrets manager—not in the cron script.

Detailed S3 automation patterns appear in automate off-site backups to S3. For broader planning, read backup and disaster recovery strategy on the cloud.

How Do You Combine Rsync and Rclone in a Layered Backup Strategy?

The strongest setups use both tools in sequence. This is not either-or for most production web stacks running PHP 8.3+ and Laravel 12 or WordPress 7.1.

1. Layer 0 — Application dump: Run mysqldump or use Laravel Spatie Backup for automated database backups.
2. Layer 1 — Local Rsync: Sync files and dumps to a local /backups partition or NAS on the same network.
3. Layer 2 — Rsync off-site: Push to a secondary VPS in another region via SSH.
4. Layer 3 — Rclone to cloud: Mirror encrypted tarballs to S3 or B2 for geographic redundancy.
5. Layer 4 — Verify restores: Monthly test restore to a staging VM. A backup you never tested is wishful thinking.

On booking platforms like Adventure Third Pole Trek, customer reservation data and uploaded documents need all four layers. A single-tool approach leaves gaps.

Example combined shell script

#!/bin/bash
set -euo pipefail

APP="/var/www/myapp"
STAMP=$(date +%Y-%m-%d_%H-%M)
DEST="/backups/daily/$STAMP"
mkdir -p "$DEST"

mysqldump -u backup -p"$DB_PASS" myapp | gzip > "$DEST/db.sql.gz"
tar -czf "$DEST/files.tar.gz" -C "$APP" storage public/uploads

rsync -av --delete "$DEST/" backup@vps2:/backups/myapp/latest/

rclone copy "$DEST/" myremote:mybucket/myapp/$STAMP/ \
  --log-file /var/log/rclone.log

find /backups/daily -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

Adjust retention to match your compliance needs. Legal-tech portals storing client documents may need 90-day minimum retention. Check your Ubuntu server backup strategies article for retention math.

What Are Common Rsync and Rclone Mistakes on Production Servers?

Most backup failures I troubleshoot are configuration errors, not tool limitations. These recur across client projects.

Rsync pitfalls

• Backing up live MySQL files without a dump. InnoDB files copied mid-write can corrupt. Always dump or snapshot first.
• Missing trailing slash confusion. rsync /src/ dest/ copies contents. rsync /src dest/ creates dest/src/. I've seen nested folder disasters from this.
• SSH key permissions. Keys must be 600. Cron running as root with a user key path fails silently unless you log stderr.
• No bandwidth limit on shared hosts. Add --bwlimit=5000 (KB/s) during business hours on constrained links.
• Forgetting --delete semantics. Without it, deleted source files linger on backup. With it, a wrong source path wipes the backup mirror.

Rclone pitfalls

• Using sync when you meant copy. rclone sync deletes remote files not present locally. One empty local folder destroys your cloud archive.
• Ignoring egress costs. Restoring 500 GB from S3 can cost Rs 4,000+ (~USD 30) in egress alone. Budget for restore drills.
• API rate limits. Google Drive throttles aggressive transfers. Lower --transfers and add --tpslimit.
• Stale credentials in cron. Rotated IAM keys break nightly jobs. Monitor exit codes with Nagios monitoring for servers or a simple email-on-failure wrapper.
• Skipping encryption. S3 bucket policies are not enough for sensitive client data. Use Rclone crypt or gpg-encrypted tarballs.

Security hardening matters too. Restrict backup SSH keys to a single command in authorized_keys. Lock S3 buckets with IAM least privilege. Follow server hardening for Ubuntu web servers and how to secure your website and server in Nepal for baseline rules.

How Do Rsync and Rclone Compare for Laravel and WordPress Backups?

Application-level backup needs differ from raw filesystem copies. Here is how each tool fits common PHP stacks.

Laravel: Spatie Backup creates zip archives containing database dumps and selected directories. Rsync those zips to a backup VPS nightly. Rclone pushes them to B2 for off-site storage. Exclude vendor/ and node_modules/ from file sync—they rebuild from Composer and npm.

WordPress: Core files are replaceable. Back up wp-content/uploads, your theme, custom plugins, and the database. Rsync handles uploads efficiently because images change incrementally. Rclone suits agencies managing dozens of client sites to one bucket with prefix per domain.

WooCommerce 11.1: Order tables grow fast. Database dumps matter more than file sync. Schedule dumps during low-traffic windows—often 2–4 AM NPT for Nepal stores.

For managed backup and restore support, see support and maintenance services and domain registration and hosting. Migration projects often reveal broken backup jobs—website migration includes pre-flight backup audits.

Reference the Amazon S3 user guide when configuring lifecycle rules to auto-expire old Rclone uploads and cut storage bills.

Key Takeaways

• Use Rsync for SSH-based, incremental, server-to-server backups with hard-link snapshots when you control both hosts.
• Use Rclone when the destination is S3, B2, Google Drive, or any remote API—and enable client-side encryption for sensitive data.
• Always dump databases before file sync; copying live InnoDB files without a snapshot risks corruption.
• Combine both in a 3-2-1 strategy: local copy, off-site VPS via Rsync, cloud mirror via Rclone.
• Test restores monthly; monitor cron exit codes; never let backup scripts run without logging.
• Match retention and encryption to your compliance needs—legal-tech and eCommerce sites need longer off-site retention.

People Also Ask

Is Rclone faster than Rsync?

Rsync is usually faster for server-to-server delta transfers because it sends changed blocks over SSH. Rclone speed depends on your cloud provider, file sizes, and parallelism settings. Large single files favour Rclone's multipart upload. Many small files favour Rsync over a direct network link.

Can Rclone replace Rsync completely?

Rclone can sync to SFTP endpoints, so it technically covers some Rsync use cases. For two Linux boxes on a fast network, native Rsync with hard links is simpler and more disk-efficient. Most teams keep Rsync for local speed and add Rclone for cloud off-site copies.

Do I need both tools for a single VPS?

A single VPS still needs off-site backups. Use Rclone alone if you have no second server. Add a cheap backup VPS (~Rs 800/month) and Rsync if you want faster restores without cloud egress fees. The 3-2-1 rule recommends at least two media types and one off-site copy.

Which tool works better with cron on Ubuntu?

Both integrate cleanly with cron. Rsync is one command with SSH flags. Rclone needs a configured remote but handles cloud auth for you. Wrap either in a shell script with set -euo pipefail, log output, and alert on non-zero exit. See Ubuntu server setup for PHP apps for baseline cron and logging patterns.

Pick the Right Tool and Test Your Restore Path

The Rsync vs Rclone for server backups question has a practical answer: Rsync for owned infrastructure and fast recovery, Rclone for cloud redundancy and provider flexibility. Production systems I maintain use both in sequence, with database dumps upstream of either tool. Start with one layer today, add the second next sprint, and schedule a restore test before you need it.

Need help designing backup automation for your Laravel, WordPress, or custom PHP stack? Contact us for a backup audit, or explore Linux system administration and Ubuntu server security best practices to harden the full pipeline.