Restic vs Borg vs Kopia 2026: Choosing the Right Linux Backup Tool

Quick summary: All three tools do client-side encrypted, deduplicated backups to object storage. Restic has the best cloud-storage support and is the easiest to teach, but is slower than alternatives on repeated runs. BorgBackup has the best deduplication ratio and is the fastest at incremental backups, but requires SSH-accessible storage (no native S3). Kopia is the newest, has a real GUI, supports parallelism out of the box, and has the best long-term outlook — but it is the youngest of the three and has fewer years of "do you trust your backups" track record. The right choice depends on your storage backend, scale, and whether you need a GUI for non-technical operators.

What All Three Have in Common

Before getting into differences, the shared baseline matters because it disqualifies a lot of older alternatives:

• Client-side encryption. Data is encrypted before it leaves the source machine; the backup destination never sees plaintext. Even if your backup repository is compromised, the data inside is protected.
• Content-addressed deduplication. Files are split into chunks, hashed, and stored once. If you back up the same 100 GB of photos to ten machines, the repository still only stores about 100 GB.
• Snapshots, not file-level copies. Each backup is a logical snapshot reference; restoring a specific point in time pulls only the chunks that snapshot needs.
• Append-only friendly. All three can run with backup repositories where the source machine has no delete permissions, mitigating ransomware that targets backups.
• Single statically-linked binary. Easy to deploy, easy to script, no runtime dependencies.

If your current backup tool does not check all five of those boxes, it is by definition a worse choice than any of these three.

Restic: The Crowd Favorite

Restic has been the most-recommended Linux backup tool since around 2019. Its appeal is simple: it Just Works with the widest range of backup destinations, including S3, B2, Azure Blob, GCS, Swift, MinIO, and any SFTP/REST endpoint.

Strengths

• Native support for almost every cloud storage provider, no extra layer needed.
• Cleanest CLI of the three — single binary, intuitive subcommands, helpful error messages.
• Mature client-side encryption with no known cryptographic weaknesses.
• Integrated repository check (restic check) with optional read-data mode.
• Largest user base and best documentation/tutorials available online.

Weaknesses

• Repeated backups are slower than Borg or Kopia because of how the chunk index is loaded into memory.
• Repository operations (prune, check) are notably slower than competitors at scale (1+ TB repositories).
• Single-threaded for many operations until very recent versions; even now, parallelism is limited.
• Memory usage grows with repository size; multi-TB repositories want 8+ GB RAM for prune operations.

Best for

Most workloads. If you do not have a specific reason to choose otherwise, Restic is the safe default. Especially well-suited to backing up many machines (laptops, servers) to S3-compatible object storage.

Quick start

# Initialize an S3 repository
export RESTIC_REPOSITORY="s3:s3.eu-west-1.amazonaws.com/my-backup-bucket/host-1"
export RESTIC_PASSWORD="long-strong-password"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

restic init

# Take a backup
restic backup /home /etc /var/log --exclude='*.tmp'

# List snapshots
restic snapshots

# Restore a single file
restic restore latest --target /tmp/restore --include /home/user/file.txt

BorgBackup: The Speed Champion

Borg has been around longer than Restic and is the deduplication champion. On repeated backups of slowly-changing data, Borg is consistently the fastest of the three and produces the smallest repository.

Strengths

• Best-in-class deduplication ratio — typically 5-15% smaller repositories than Restic for equivalent data.
• Fastest incremental backups, especially for "many small changed files" workloads.
• Compression options: lz4 (default, fast), zstd (better ratio, modern default for many users), zlib, lzma.
• Mature codebase with a long track record of restore reliability.
• BorgBase and other hosted services offer turnkey Borg-as-a-service for those who do not want to run their own SSH endpoint.

Weaknesses

• No native S3/object storage support. Borg expects a remote SSH endpoint. To back up to S3, you must layer rclone, JuiceFS, or run Borg on an EC2 instance with mounted storage. This is the biggest single drawback in 2026.
• Single-threaded backup process — does not exploit modern multi-core CPUs.
• Repository format is unique to Borg; no interop with other tools.
• Borg 2 (rumored major release) has been "coming soon" for years; the current 1.x line is mature but not actively gaining major features.

Best for

Backing up Linux servers to a dedicated SSH-accessible backup server (or BorgBase). Workloads where deduplication ratio matters more than cloud-storage flexibility. Long-running setups where the existing Borg infrastructure already works fine and there is no reason to migrate.

Quick start

# Initialize a remote Borg repo over SSH
borg init --encryption=repokey-blake2 backup-user@backup-host:/backups/host-1

# Take a backup
borg create --stats --progress \
    backup-user@backup-host:/backups/host-1::host-1-{now} \
    /home /etc /var/log

# List archives
borg list backup-user@backup-host:/backups/host-1

# Restore
borg extract backup-user@backup-host:/backups/host-1::host-1-2026-05-13

Kopia: The Modern Challenger

Kopia is the youngest of the three (first stable release 2019) and the most actively-developed. It targets the modern cloud-native use case and ships with several capabilities the older tools lack.

Strengths

• Real GUI — KopiaUI is a packaged desktop application that makes it accessible to non-CLI users.
• Native parallelism throughout; backups and restores both scale across cores.
• Native support for S3, B2, Azure, GCS, SFTP, WebDAV, and more — competitive with Restic on backend coverage.
• Built-in repository server mode that turns one node into a multi-client backup server, useful for office environments.
• Configurable splitting algorithms, allowing tuning for different data types.
• Newest codebase, modern Go, easy to contribute to.

Weaknesses

• Newest of the three, so the "I have been using it for 7 years and never had a restore problem" track record is shorter.
• Documentation is improving but lags Restic's quality in some areas.
• Slightly higher CPU usage than Borg on equivalent backups (the cost of parallelism).
• The combination of CLI + GUI + server modes makes it more complex to wrap your head around than Restic.

Best for

New deployments where you want a future-proof, actively-maintained tool. Mixed environments with both technical and non-technical users (the GUI matters). Office or small-team scenarios where the repository server mode simplifies multi-machine backups.

Quick start

# Connect or create an S3 repository
kopia repository create s3 \
    --bucket=my-backup-bucket \
    --endpoint=s3.eu-west-1.amazonaws.com \
    --access-key=... --secret-access-key=... \
    --password="long-strong-password"

# Take a snapshot
kopia snapshot create /home /etc /var/log

# List snapshots
kopia snapshot list

# Restore
kopia snapshot restore <snapshot-id> /tmp/restore

Real Benchmark: Backing Up a 250 GB Dataset

We backed up a representative server dataset (250 GB across roughly 850,000 files: a mix of source code, document archives, photo library, and a small database dump) to identical Hetzner Cloud Object Storage buckets. All three tools ran on the same source VM with the same compression where applicable.

Borg wins on raw deduplication and incremental speed; Kopia wins on parallelism (initial backup, full restore); Restic is competitive everywhere but never the fastest. All three tools successfully restored byte-identical data to the source.

The Cloud-Storage Question

This is the single biggest practical differentiator in 2026.

• Restic and Kopia talk directly to S3-compatible object storage. Set credentials, point at the bucket, done.
• Borg needs an SSH endpoint. Workarounds: BorgBase (commercial hosted service, good if you want pay-someone-else), rclone + crypt mount (works but adds a dependency), or Borg-on-EC2-with-attached-EBS (defeats much of the cost savings of object storage).

If your backup destination is "object storage in a cloud," Borg is the harder choice. If your backup destination is "a dedicated backup server in your data center," Borg is wonderful.

Restore Strategy: The Most-Skipped Step

The depressingly common pattern: a team adopts a backup tool, configures backups, watches them succeed, and never tests a restore until the day they need one. By that point, half the time something is wrong (wrong backup destination, lost passphrase, corrupted repo, missing exclude path that excluded the actual data).

Mandatory restore tests, regardless of tool choice:

1. Monthly: restore one random file from each repository. Verify it matches a known-good source.
2. Quarterly: restore an entire snapshot to a separate machine. Run application smoke tests against the restored data.
3. Annually: full disaster recovery drill — pretend the source machine is gone, rebuild from scratch using only the backups and your runbook.

If your annual drill works, you have backups. If you have never run one, you have wishes.

Operational Patterns That Apply to All Three

1. Set retention policies

Without retention, repositories grow forever. The standard pattern (sometimes called "GFS retention"):

• Daily backups: keep 14
• Weekly backups: keep 8
• Monthly backups: keep 12
• Yearly backups: keep 7

All three tools support this pattern with one command. Run prune monthly (it is the most expensive operation; do not run it on every backup).

2. Use a separate, immutable repository for off-site copies

The 3-2-1 rule (3 copies, 2 different media, 1 off-site) still applies. Run two parallel backup jobs to two different repositories, ideally in different geographic regions or with different providers.

3. Encrypt the repository password too

The backup encryption key is as critical as any other secret. Store it in a password manager, vault, or HSM — not in /etc/restic.conf.

4. Monitor backup success

A silent failure is worse than no backups at all because it produces false confidence. Wrap your backup script in a wrapper that pings a healthcheck service (healthchecks.io, deadmanssnitch.com, your own Prometheus pushgateway) on success. Alert on missed pings.

Frequently Asked Questions

Which one is most secure?

All three use authenticated encryption with no known cryptographic weaknesses as of 2026. Borg uses Blake2 + AES, Restic uses Poly1305-AES, Kopia uses AES-GCM-HMAC-SHA256. The differences are not security-relevant in practice; key management is the real attack surface.

Can I migrate between them?

No direct repository conversion exists. The migration path is "restore from old tool, back up with new tool." Plan for double-storage during the transition window.

What about rsnapshot, rdiff-backup, duplicity?

All older, all functional, none have meaningful deduplication. Move to one of the three modern tools unless you have a specific reason not to.

Should I use ZFS snapshots instead?

ZFS snapshots are excellent for local point-in-time recovery but are not "backups" in the disaster-recovery sense — they live on the same disk as the data. Use ZFS snapshots and ship a backup off the machine with one of these tools.

What about file metadata (xattrs, ACLs)?

All three preserve standard POSIX permissions. xattrs and ACLs are tool-specific:

• Restic: yes, all metadata preserved by default
• Borg: yes, all metadata preserved by default
• Kopia: yes, fully supported in current versions

Which has the best Windows support?

All three run on Windows in 2026. Kopia has the most polished Windows experience (native installer, GUI). Restic and Borg work via WSL or native binaries with rougher edges.

A Real-World Decision Matrix

Three actual scenarios and the right tool for each:

Scenario 1 — Backing up 30 production Linux servers to AWS S3. Right answer: Restic. Cloud-native, easy to script, mature operator-side tooling. Borg would require an EC2 instance running 24/7 to act as the SSH endpoint, eroding cost savings.

Scenario 2 — Mixed office of 50 laptops, half technical/half not, backing up to a NAS in the office. Right answer: Kopia. The GUI matters, the repository server mode handles the multi-client case cleanly, and modern Linux/macOS/Windows support means one tool for everyone.

Scenario 3 — A self-hosted homelab with a dedicated backup VM, six servers backing up to it via SSH. Right answer: Borg. Optimal deduplication, fastest incremental backups, the SSH-only model is exactly what this scenario already has. No reason to add cloud-storage complexity.

Further Reading from the Dargslan Library

• Storage & Backup category — strategies, tools, and disaster recovery patterns.
• Linux Tutorials category — practical guides for Linux administration.
• Free cheat sheet library — printable references for restic, borg, and kopia commands.
• Dargslan eBook library — comprehensive Linux administration and storage management courses.

The Bottom Line

You almost cannot pick wrong among the three — they all do client-side encrypted deduplicated backups well. Pick Restic by default for cloud-storage destinations, pick Borg if your destination is SSH-accessible and you want maximum dedup, pick Kopia if you have non-technical users or want the most modern codebase. Whichever you choose, test your restores monthly. The tool selection matters less than the discipline of actually using it.