Learn Rsync - Alternatives & the Backup Ecosystem

#Introduction

After 18 episodes, you know rsync is outstanding — for synchronization. Episode 19 positions rsync on a wider map: the modern backup ecosystem. The question isn't "which is best", but "which problem are you solving" — because rsync, rclone, restic, borg, and tar/dd handle different problems.

Understanding these differences is a step toward engineering maturity: not everything must be forced through rsync, and not everything must be forced through a managed backup tool. Sometimes the answer is a combination.

#The Ecosystem Map

Tool	Core strength	Problem it solves
rsync	One-way synchronization, delta-transfer	Mirror, daily backup, migration
rclone	Cloud object storage	Sync to S3/B2/GCS/etc.
restic	Managed dedup + encryption	Backups with a secure repository
borg	Dedup + encryption + compression	Deduplicated backups with history
tar / dd	Archive & image-level	Full archives, boot images, disk cloning

#rsync: Synchronization

Already mastered throughout this series. Its main advantages: delta-transfer makes re-syncing cheap, and the result is an ordinary directory — readable directly, browsable, no special tool needed. Its weaknesses: no at-rest encryption (unless the filesystem is encrypted), and no cross-backup dedup (except the --link-dest hardlink pattern).

#rclone: Cloud Object Storage

rclone is the "rsync for the cloud": synchronizing to and from object storage — S3, Google Cloud Storage, Backblaze B2, and dozens of other providers. Its syntax resembles rsync (rclone copy), it has delta-check (size + modtime + hash), and it supports a built-in encrypt remote.

rclone to S3

rclone copy /backup/daily/ b2:bucket-name/daily/ --progress

When to use it: when your target is cloud object storage — that's where rsync gives up (rsync doesn't understand S3/B2). We'll compare them again in episode 22.

#restic: Dedup + Encryption

restic is a managed backup tool with three strengths: deduplication across snapshots, built-in encryption (client-side), and snapshot management (view, delete, restore via dedicated commands). Data is stored in its own repository format — not an ordinary directory.

Backup and restore with restic

restic -r b2:bucket/backup init
restic -r b2:bucket/backup backup /home/data
restic -r b2:bucket/backup restore latest:/ --target /restore

Its security is strong: authenticated encryption — tampered files are detected. The downside: snapshots can't be read directly without restic; you need the tool to access data. When to use it: backups that are secure and deduplicated, especially to the cloud.

#borg: Dedup + Encryption + Compression

borg (BorgBackup) is similar to restic, with one distinctive strength: highly efficient chunk-level deduplication and integrated compression (zlib, lz4, zstd). It's known for the best space ratio among open source backup tools — economical for datasets that change a lot but stay similar across snapshots.

Backup with borg

borg init --encryption=repokey /backup/borg-repo
borg create /backup/borg-repo::{hostname}-{now} /home/data
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12

Note borg prune — rotation (daily/weekly/monthly) is built in, no manual script needed like the rsync pattern in episode 9. When to use it: local/NAS backups with very tight space requirements.

#tar and dd: Image-Level

tar — packs files into one archive (.tar.gz). Suited for one-off archives: handing over data, a snapshot before an upgrade, or moving a directory.
dd — copies the raw blocks of a device into an image file. Suited for image-level: full disk cloning, boot sector backup, or capturing MBR/GPT.

A tar archive and a dd image

tar czf /backup/project-$(date +%F).tar.gz /home/data/
dd if=/dev/sda of=/backup/disk-image.img bs=4M status=progress

Both are image-level: they take full space, no dedup, no incremental — but they're the only way to capture the entire state (including bootloader, partitions, and "deleted" files that still live in blocks).

#A Quick Comparison Table

Need	rsync	rclone	restic	borg	tar/dd
Sync/mirror	✅	✅	❌	❌	❌
Repeated daily backup	✅	✅	✅	✅	❌
Deduplication	Partial	❌	✅	✅	❌
At-rest encryption	❌	Optional	✅	✅	❌
Direct access without a tool	✅	✅	❌	❌	❌
Cloud object storage	❌	✅	✅	Partial	❌
Image/disk cloning	❌	❌	❌	❌	✅

#The Best Combination

The greatest strength comes from combination, not competition. A sane backup architecture:

Daily mirror with rsync — fast, directly readable, --link-dest rotation (episode 9).
Encrypted deduplicated backup with restic/borg — from the mirror or directly from the source, as a safety net against disaster (encryption + dedup).
Cloud copy with rclone — to replicate important data to another location (off-site).
All scheduled by cron (episode 10), with exit codes monitored (episode 20).

The combined pipeline

rsync -avh /home/data/ /backup/mirror/              # 1. local mirror
restic -r /backup/restic backup /home/data          # 2. encrypted dedup
rclone copy /backup/restic b2:bucket/restic-copy    # 3. off-site

Each layer answers a different threat: rsync protects against user error (browsable), restic against corruption/tampering (authenticated encryption), rclone against local disaster (off-site).

Important

The 3-2-1 principle still holds in the era of modern tools: 3 copies of your data, 2 different media, 1 in a different location. Rsync + restic/borg + rclone is a practical way to achieve 3-2-1 — but remember, all those layers are only worth anything if they're tested with restores regularly.

#Closing

In this episode you've mapped the backup ecosystem.

Key takeaways:

rsync for synchronization/mirroring; rclone for cloud object storage.
restic/borg for dedup + encryption; tar/dd for archives and image-level.
restic: repository + authenticated encryption; borg: chunk dedup + built-in rotation (borg prune).
tar/dd capture the entire state, but waste space and have no incremental.
Combination: rsync mirror + restic/borg backup + off-site rclone = a 3-2-1 architecture.

In episode 20 we make sure everything is monitored: monitoring & logging — rsync logs, exit codes, email on failure, Zabbix/Prometheus alerting integration via a cron wrapper, rsyslog for daemon mode, and periodic backup log reviews. See you in episode 20!