Restic vs Borg vs Kopia: Backups That Actually Deduplicate

Let’s be honest. You’ve heard someone say, “I just rsync to a NAS every night, I’m backed up.” Then their dog walked across the keyboard, they fat-fingered an rm -rf, and suddenly that NAS has nothing but the void staring back. rsync is a sync tool. It’s fantastic for keeping two directories in lockstep. It is not a backup strategy.

A backup tool needs three things: deduplication (don’t store the same 500 MB Docker image fifty times), encryption (so your NAS theft doesn’t leak your passwords), and immutability (so an accident on the source doesn’t cascade to the backup). rsync has zero of these.

Restic, Borg, and Kopia all have all three. They’re genuinely different, and they’re all genuinely good.

Why You Need Real Backup Tools

Here’s the thing: every byte you back up costs you storage, bandwidth, or money. If you’re backing up your home lab across the internet (or storing snapshots locally), you’re moving a lot of data. Deduplication means that when your Postgres database records 50 GB of mostly-identical snapshots, the backup tool sees the common 40 GB once and stores 10 GB of changes. Content-addressed chunking lets Restic, Borg, and Kopia identify “this 16 KB block is identical to one we’ve already seen” and store it once, with a pointer.

Encryption means your backup is useless to anyone without the key—even your hosting provider, even if someone nabs your NAS off the curb.

And immutability (mostly through snapshots and append-only storage) means that if your dog deletes 200 files today, your backup from two weeks ago is still intact. You can restore the whole thing, or cherry-pick files.

Restic: The Swiss Army Knife

Restic is a single binary. You download it, you run it, it works on macOS, Linux, Windows, FreeBSD. You initialize a repository, you back up, you restore. No daemon, no complex setup.

# Install (macOS/Linux)
curl -L https://github.com/restic/restic/releases/download/v0.17.1/restic_0.17.1_linux_amd64.bz2 | bunzip2 | sudo tee /usr/local/bin/restic > /dev/null
chmod +x /usr/local/bin/restic

# Initialize a repository (local example)
restic init --repo /mnt/backup

# Or remote (S3, B2, SFTP, Backblaze, etc.)
restic init --repo s3:s3.amazonaws.com/mybucket/backup

# Take a snapshot
restic backup /home/data --repo /mnt/backup

# List snapshots
restic snapshots --repo /mnt/backup

# Restore a specific snapshot
restic restore 5d5f... --target /restore --repo /mnt/backup

Restic backs up everything as content-addressed blobs. Each blob is identified by its SHA-256 hash. Identical chunks in different files? Same blob, stored once. Its design assumes the repository is dumb storage—you can throw Restic repositories at S3, SFTP, local disks, even Backblaze B2, and it just works.

The downside: Restic is simple, which means less built-in compression (lz4 only), no client-server architecture for teams, and the web UI ecosystem is community-built (like Webrestic or REST Server). For a solo home lab? Perfect.

Borg: The Linux Native

Borg is opinionated. It’s Linux-first (macOS is possible but janky, Windows is a no-go). It has opinions about compression—lz4, zstd, lzma, and an auto mode that chooses based on file type. Those opinions make backups smaller.

# Install (apt on Debian/Ubuntu)
sudo apt install borgbackup

# Initialize a repository
borg init --encryption=repokey /mnt/backup

# Backup with auto compression
borg create /mnt/backup::home-2026-04-25 /home/data

# List archives (snapshots)
borg list /mnt/backup

# Mount an archive to browse it
mkdir /tmp/restore
borg mount /mnt/backup::home-2026-04-25 /tmp/restore
# Browse /tmp/restore, copy what you need
umount /tmp/restore

Borg’s secret weapon is borgmatic, a wrapper that reads YAML and automates everything:

# borgmatic config
source_directories:
  - /home/data

repositories:
  - label: local
    path: /mnt/backup

retention:
  keep_daily: 7
  keep_weekly: 4
  keep_monthly: 12

checks:
  - name: repository
  - name: archives

before_backup:
  - echo "Starting backup..."

after_backup:
  - echo "Backup done."

Run borgmatic once a day via cron, and Borg handles snapshots, retention, and consistency checks. The tradeoff: Borg doesn’t play well with remote SSH repositories (it can, but it’s not the easy case), and the encryption model assumes you control both ends.

Kopia: The Modern Option

Kopia is the new kid and it shows. It has a web UI (localhost:51515 by default), a CLI, and desktop apps. It’s modular—you can use the CLI for automation, or the UI for browsing.

# Install
sudo apt install kopia

# Create a repository
kopia repository create filesystem --path=/mnt/backup

# Snapshot a directory
kopia snapshot create /home/data

# List snapshots
kopia snapshot list

# Mount snapshots via FUSE
mkdir /tmp/kopia-mnt
kopia mount /tmp/kopia-mnt
# Browse /tmp/kopia-mnt

Kopia’s UI is actually usable—you can see snapshots, drill into files, schedule backups with policies. It supports S3, Azure, Google Cloud, and local storage. Parallel uploads mean faster backups to remote backends.

The trade: Kopia is newer and less battle-tested than the others. The feature set is powerful but the ecosystem is smaller.

Deduplication and Encryption

All three use content-addressed chunking. Restic and Borg use variable-size chunks (around 1 MB); Kopia defaults to fixed 4 MB chunks (configurable). The key insight: if your /home/data has 200 VMs with Debian base images, and the common 300 MB core is identical, all three tools store it once, not 200 times. Compression amplifies this—Borg’s zstd on top of dedup can shrink your backups by 10–50× depending on your data.

Encryption: all three encrypt by default. Restic uses AES-256 with scrypt key derivation. Borg uses AEAD (AES-256-OCB or ChaCha20-Poly1305). Kopia uses AES-256-GCM. All are overkill for a home lab, all are solid for production. The difference: Restic and Kopia use master keys you remember (or store in a password manager); Borg has a “repokey” model where the key is stored in the repository itself (but you still need a passphrase to unlock it).

Automation and Restoration

Restic cron:

0 2 * * * root restic backup /home/data --repo /mnt/backup --quiet
0 3 * * * root restic forget /mnt/backup --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune --quiet

Borg via borgmatic:

0 2 * * * root /usr/bin/borgmatic --stats --syslog-verbosity 1

Kopia policy: Define it in the web UI or CLI:

kopia policy set /home/data --interval=6h --retention-daily=7 --retention-weekly=4 --retention-monthly=12

Here’s the part nobody does: restore testing. Once a month, pull a random file from a backup and make sure it’s actually there and not corrupted. All three tools let you:

• Mount a snapshot (Borg: borg mount, Kopia: kopia mount, Restic: REST Server or third-party UI)
• Verify checksums after restore
• Check logs for warnings during restore

If you’re not testing restores, you don’t have backups. You have expensive data that might be recoverable.

Which One?

Use Restic if you want simplicity, portability (macOS/Windows/Linux), and you’re okay with a CLI or community web UI. Pair it with Backblaze B2 or S3 for offsite. Solo home lab champion.

Use Borg if you’re Linux-only and compression matters—media servers, Plex libraries, that sort of thing. borgmatic makes it effortless. If you have a dedicated backup server on the same network, Borg’s SSH model is unbeatable.

Use Kopia if you like GUIs, want to share backups with team members, or need the extra polish. It’s modern, it has a web console, and it’s getting better every release.

All three will save your bacon when you need them. Pick one, set it up, and then go test a restore.