Restic vs Borg vs Kopia: Which Backup Tool (2026)

By LK Wood IV · Published 2026-07-21 · Updated 2026-08-24 · ~11 min read · St. Louis County, MO

The short version

Most comparisons of these three tools open with a feature grid and close with “it depends.” That grid is where the errors live. The single most-repeated claim in this search result — that restic has no compression — has been wrong since August 2022, and it is still sitting in AI summaries and in blog posts updated this year.

So here is the correction first, then a decision framework that actually resolves.

restic added compression in v0.14.0, released 2022-08-25, tied to repository format version 2. The release notes call it “the most requested feature: compression” (restic v0.14.0 release notes). Repository format 2 is now the current default for new repositories (restic docs). All three tools compress. That axis is dead.

The axis that narrows it fastest is where the backup lands. restic and Kopia can write directly into cloud object storage. Borg cannot — its documented transports are a local path or an SSH remote. That one difference eliminates a candidate for most people in about thirty seconds.

Be clear about what that buys you, though: destination is a compatibility filter, not the whole decision. It tells you which tools are even eligible. What separates the survivors is everything after — whether you need a GUI, which operating systems you have to cover, how much CLI you want to learn, and how you intend to scope compression. This guide runs the filter first because it is the cheapest way to cut the field, then does the real comparison on what remains.

Why the “restic has no compression” myth persists

There is a real fact underneath the wrong claim, and it is worth knowing because it may apply to you.

Compression only works on a repository at format version 2 or later. Old repositories are not auto-upgraded. To get compression on a repository created before 0.14.0 you run migrate upgrade_repo_v2, which verifies integrity and bumps the version, then prune to compress existing metadata. After that, new backup data is compressed, and the repository compresses progressively over time. If you would rather not wait for that drift, prune --repack-uncompressed forces existing data to be rewritten compressed in one pass. Format 2 repositories are readable only by restic 0.14.0 and newer (restic docs).

So a repository someone created in 2020 and never migrated genuinely stores uncompressed data in 2026. That is almost certainly where the folklore comes from — that, and the 2019-era third-party comparisons still in circulation, whose restic criticisms predate compression entirely. Commenters passing those around on r/selfhosted routinely flag the date themselves.

Current restic exposes --compression with five settings: off, fastest, auto (the default), better, max, also settable via RESTIC_COMPRESSION. Each step up spends more CPU to save bandwidth and space (restic tuning docs). Two of those — fastest and better — are new; restic 0.19.0 on 2026-06-09 added the extra zstd levels (changelog). The original 0.14.0 set was just auto/max/off.

If you want the working setup rather than the theory, our automated offsite backups with restic walk-through covers repository init, retention and scheduling end to end.

Decide by where the backup lands

The target is a bucket (S3, B2, Wasabi, Azure, GCS)

restic and Kopia. Not Borg.

restic documents native support for local paths, SFTP, its own REST Server, Amazon S3, MinIO, any S3-compatible endpoint, Wasabi, Alibaba Cloud OSS, OpenStack Swift, Backblaze B2, Azure Blob Storage, Google Cloud Storage, and rclone as a bridge to everything else (restic docs). One documented gotcha worth acting on: because of error handling in the B2 library restic uses, the project recommends reaching Backblaze B2 through its S3-compatible API rather than the native B2 backend. Same source.

Before you pick either, one requirement that belongs in this decision and almost never appears in these comparisons: a bucket your backup client can write to is a bucket your backup client can delete. If the machine being backed up is compromised, credentials sitting on it can be used to wipe the repository — which is exactly the scenario offsite backup exists to survive. Neither restic nor Kopia solves that for you; the storage layer does. Turn on object lock or versioning at the bucket (Backblaze B2 and S3 both support it), give the backup client an application key scoped to write-and-list without delete, and run pruning as a separate privileged job rather than from the client. Then actually test a restore. A bucket target without those three things is a copy, not a backup.

Kopia documents S3 and S3-compatible storage, Azure Blob, Backblaze B2, Google Cloud Storage, Google Drive (native, experimental), WebDAV, SFTP, rclone, plain filesystem targets, and the Kopia Repository Server (Kopia docs). Kopia’s rclone support is marked experimental, with only Dropbox, OneDrive and Google Drive confirmed tested — which matches the community report of a user moving from Kopia to restic after OneDrive-over-rclone proved unreliable.

Borg documents no object-storage backend anywhere in its quickstart or FAQ. Note the phrasing: this is established by absence, not by an explicit statement from the project. But the FAQ actively points the other direction, recommending you run the Borg client where the source data is local and borg serve over SSH where the repository storage is local, and avoid NFS or other network filesystems for repository storage (Borg FAQ).

The target is an SSH box you control

Borg is at home here, and this is the case where it wins on merit rather than on habit.

Borg initializes and accesses repositories on remote hosts over SSH, and the docs are explicit that this is fastest and easiest when Borg is installed on the remote host (Borg quickstart). If you cannot install Borg at the far end, you can mount the remote filesystem with something like sshfs and treat it as local — with the documented caution that not every filesystem is stable enough for backup use.

Borg also has the widest compression menu of the three (Borg help docs):

• none
• lz4 — very high speed, very low ratio; this is the default
• zstd[,L] — levels 1 to 22, default 3
• zlib[,L] — levels 0 to 9, default 6
• lzma[,L] — levels 0 to 9, default 6
• auto,C[,L] — per-chunk heuristic that tries lz4 first to see whether data compresses
• obfuscate,SPEC,C[,L] — pads compressed size to frustrate fingerprinting attacks based on observable chunk sizes

That last one has no advertised equivalent in restic or Kopia. If your threat model includes an adversary who can see stored chunk sizes on a repository host you do not fully trust, it is a genuine reason to pick Borg.

Borg also documents borg mount, which exposes a repository or archive as a FUSE filesystem for browsing and single-file restores. Limitation: the current FUSE implementation does not carry special filesystem flags or ACLs, and the docs recommend the nosymfollow mount option (or a container/chroot) so symlinks inside a mounted archive cannot reach outside it (Borg mount docs).

If your SSH box is a NAS or a ZFS server, the storage layer choices under it matter as much as the backup tool — see Proxmox vs TrueNAS vs Unraid as a storage backend and the NAS drives worth buying.

The fleet includes Windows

Borg is out. Its official standalone binaries cover Linux, FreeBSD and macOS on x86-64, with ARM via a third-party builder. Windows 10’s Linux Subsystem is described as experimental and not much tested, with FUSE omitted; Cygwin carries the identical experimental disclaimer (Borg installation docs).

restic backs up from Linux, BSD, macOS and Windows (restic.net), and on Windows the --use-fs-snapshot option drives Volume Shadow Copy Service, with -o vss.timeout (default 120 seconds) and -o vss.exclude-volumes to tune it (restic backup docs). Kopia supports Windows 10 or later 64-bit via CLI binary, GUI installer, Scoop and winget; macOS 10.11+ via binary, installer and Homebrew; and Linux amd64/armhf/arm64 via RPM and DEB repos, AUR and Docker images (Kopia installation).

One more restic detail that matters for mixed fleets: multiple hosts writing into one repository is officially supported and encouraged, because it increases deduplication across machines (restic backup docs).

What each tool needs installed on the far end

This is the question feature grids never answer, and it is the one that breaks deployments.

The Borg row is the whole story. Borg is a client/server design in practice: to get its performance you want the Borg binary at both ends. restic and Kopia treat the far end as dumb storage. If your offsite target is a friend’s NAS, a rented VPS, or a Backblaze bucket where you cannot install arbitrary software, that constraint decides for you before any benchmark does.

Version status is a real differentiator right now

Borg’s current stable is 1.4.5, published 2026-07-18 at 22:36 UTC per the GitHub release API — Borg’s own changelog dates it 2026-07-19, which is the same release read in a different timezone. Borg 2.0 has been in beta for years and the newest prerelease is 2.0.0b22, published 2026-07-22 — no release candidate, no stable 2.0 (Borg releases API). The project’s own release page tells you it is beta quality, for testing, and not to point it at production backup repositories (2.0.0b22 release notes, which add that with the new PACKS format you should rather expect alpha-level stability).

Community reports corroborate the cost of ignoring that. At least one r/selfhosted user upgraded to a Borg 2 beta and got stranded on a repository that was neither forward nor backward compatible; another user corrected the thread by pointing out the betas are not compatible with each other. Treat that as anecdote, not spec — the official warning says only “not for production,” not that the betas are mutually incompatible — but it lines up with the direction of that warning.

restic 0.19.1 (2026-07-05) and Kopia 0.23.1 (2026-06-16) are both on normal release cadences. The Kopia release is a bugfix for a rare race condition that could cause data loss, which is a reason to be current rather than a reason to avoid it.

What the benchmarks actually show (and what they don’t)

Thin, and contradictory. Here is everything credible we found.

deajan/backup-bench is the only reproducible-by-design suite, but it is stale — last updated 2022-10-03. Dataset: Linux kernel sources checked out at v5.19 then v5.18, 4.18 and v3.10, with the initial git directory at 4.1 GB across 5,039 directories and 76,951 files. Source host a Xeon E3-1275 with 64 GB RAM on XFS; remote target an AMD Turion II Neo N54L with 6 GB RAM on ZFS+XFS. Local initial backup: Borg 1.2.2 at 41s / 257,300, restic 0.14.0 at 23s / 260,520, Kopia 0.12.0 at 10s / 259,780 (the README’s size column carries no unit, so we do not supply one). Remote restore: Borg 244s, restic 28s, Kopia 258s (backup-bench README).

computingforgeeks is recent (updated 2026-03-31) and states its method — Ubuntu 24.04.4 LTS, 2 vCPU, 4 GB RAM, 30 GB SSD, BorgBackup 1.2.8, restic 0.16.4, Kopia 0.22.3, local filesystem repos, timed with /usr/bin/time -v. First backup: Borg 7.81s, restic 8.10s, Kopia 4.65s. Incremental: Borg 0.70s, restic 0.81s, Kopia 0.28s. Restore: Borg 0.16s, restic 3.67s, Kopia 4.39s. Peak memory on first backup: Borg 75 MB, restic 111 MB, Kopia 176 MB (computingforgeeks). The dataset is 370 MB across 1,957 files — far too small to project onto a multi-terabyte homelab, and the tool versions already trail current releases.

Those two sources point in opposite directions on restore, and they are not measuring the same thing: one has restic restoring roughly 9x faster than Borg over a remote transport, the other has Borg restoring roughly 23x faster than restic from a local repository. Different transports, datasets and versions — which is exactly why neither settles the question. Restore speed is unsettled. Anyone who ranks these three tools on speed with confidence is reading one benchmark and ignoring the other.

We also found a widely linked comparison publishing throughput figures like “180-220 MB/s” with no named author, no hardware spec, no tool versions and no reproducible commands. We are not citing it as evidence.

What competing guides skip (our angle)

One. The compression correction, with the version. restic 0.14.0, 2022-08-25, repository format v2, five modes today. Stating “all three compress” is not enough — readers need to know their old repository needs migrate upgrade_repo_v2 plus prune, and that after migration the repository only becomes readable by restic 0.14.0 or newer.

Two. The memory claims. The persistent line that restic’s RAM appetite makes it unsuitable for a small VPS traces to 2019-era write-ups that predate repository format v2 and compression entirely. restic’s official docs contain no RAM formula and no per-terabyte figure — only that limiting usable CPU cores slightly reduces memory use, that the backend can add a similar amount, and that temporary space equals the pack size multiplied by the number of backend connections plus one. Default pack size is 16 MiB, tunable with --pack-size or $RESTIC_PACK_SIZE; larger packs mean fewer files in the repository and better upload performance (restic tuning docs). Borg’s guidance is equally qualitative: have enough RAM for the repository index, chunks cache and files cache. Nobody publishes numbers. Treat the 111 MB / 75 MB / 176 MB peaks above as one 370 MB test, not as a spec.

Three. Plenty of people don’t run these bare. In the r/selfhosted threads we read, Backrest (a restic wrapper) is the single most-recommended answer, with autorestic and borgmatic close behind, and Vorta as the Borg desktop GUI. Comparing only the three binaries misses a layer that a lot of real deployments actually have. That is community sentiment from two 2024 threads with a small, self-selected sample — corroborate before betting on it — but it matches how homelabs actually look.

Four. Cloud egress. Kopia’s periodic maintenance reads from the repository. On a provider that charges for egress, that is a recurring line item nobody puts in the feature grid. Community-reported, not vendor-documented, but easy to verify against your own bill.

Five. Kopia’s honesty about its own encryption is a decent signal of doc quality: AES-256 and ChaCha20, with a footnote that the marketing term for this arrangement is imprecise (Kopia features). Kopia also scopes compression per policy — algorithm, minimum and maximum file size, and which extensions to compress — rather than one global setting (Kopia compression docs). For a laptop full of already-compressed media next to a server full of text logs, that is the more precise control.

Our call. Two of these are close enough that the tiebreaker has to be named honestly rather than asserted.

Bucket destination, command-line comfortable, mixed OS: restic — not because Kopia can’t do it, but because restic’s single-binary, one-flag operation has less surface to learn and its VSS handling on Windows is documented in more depth. If you would rather have a GUI and per-policy control than a smaller CLI, Kopia is the better fit for the same job, and calling it a tie would be fair.

Bucket destination, non-technical users or desktops to cover: Kopia — KopiaUI is the only official GUI of the three, and per-policy compression means one repository can hold a media laptop and a log server without compromise.

SSH destination you fully control: Borg 1.4.5 — not 2.0. Be precise about why: Borg has the widest choice of compression algorithms (including obfuscate, which nothing else advertises), while Kopia has the finest compression scoping (per policy, by file size and extension). Those are different axes. Pick Borg for the algorithm menu and the SSH-native design, not on a general “most control” claim. And whichever you pick, the tool that matters is the one that restores — in the threads we read, the single most-cited reason people arrive at all three is a Duplicati restore that failed when it was needed.

Backups are a layer, not a product, and the 3-2-1 backup rule is the strategy that layer serves — three copies, two devices, one off-site, and RAID is none of them. Snapshots on the source and a proper 3-2-1 target are separate jobs — see Sanoid and Syncoid for ZFS snapshots and Proxmox Backup Server in a 3-2-1 layout.

Related reading

• The 3-2-1 backup rule for homelabs — the strategy this tool choice serves: three copies, two devices, one off-site
• Automated offsite backups with restic — our step-by-step restic setup, including repository format v2 and retention
• Vaultwarden vs Bitwarden — your password vault is the first thing that belongs in these backups
• Proxmox Backup Server in a 3-2-1 layout — where a file-level tool fits next to VM-level backup
• Sanoid and Syncoid for ZFS snapshots — snapshot layer under any of these three
• Best NAS hard drives — the drives your SSH-reachable repository should live on
• Proxmox vs TrueNAS vs Unraid as a storage backend — picking the box that hosts the repository

Sources

• https://github.com/restic/restic/releases/tag/v0.14.0
• https://raw.githubusercontent.com/restic/restic/master/CHANGELOG.md
• https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• https://restic.readthedocs.io/en/stable/040_backup.html
• https://restic.readthedocs.io/en/stable/045_working_with_repos.html
• https://restic.readthedocs.io/en/stable/047_tuning_parameters.html
• https://restic.net/
• https://api.github.com/repos/restic/restic/releases/latest
• https://borgbackup.readthedocs.io/en/stable/quickstart.html
• https://borgbackup.readthedocs.io/en/stable/installation.html
• https://borgbackup.readthedocs.io/en/stable/faq.html
• https://borgbackup.readthedocs.io/en/stable/usage/help.html
• https://borgbackup.readthedocs.io/en/stable/usage/mount.html
• https://api.github.com/repos/borgbackup/borg/releases
• https://github.com/borgbackup/borg/releases/tag/2.0.0b22
• https://kopia.io/docs/repositories/
• https://kopia.io/docs/features/
• https://kopia.io/docs/advanced/compression/
• https://kopia.io/docs/installation/
• https://api.github.com/repos/kopia/kopia/releases/latest
• https://raw.githubusercontent.com/deajan/backup-bench/main/README.md
• https://github.com/deajan/backup-bench
• https://computingforgeeks.com/borg-restic-kopia-comparison/
• https://www.reddit.com/r/selfhosted/comments/1dc0lv0/torn_between_restic_and_borg/
• https://www.reddit.com/r/selfhosted/comments/1c0pj9r/shoutout_for_restic_and_kopia_as_backup_solutions/