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

By LK Wood IV · Published 2026-07-21 · Updated 2026-09-28 · ~14 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. One repeated claim in the comparisons reviewed for this guide says restic has no compression. It has been wrong since August 2022, yet it still appears in AI summaries and 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 difference can eliminate a candidate in about thirty seconds.

Destination is a compatibility filter. It tells you which tools are eligible. The remaining choice turns on the GUI, supported operating systems, CLI complexity and compression controls. This guide applies the cheap filter first, then compares 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).

A repository created in 2020 and never migrated can therefore remain uncompressed in 2026. That fact explains some accurate reports about old repositories. Third-party comparisons from 2019 also predate compression entirely. Neither point establishes that a current restic repository lacks the feature.

Current restic exposes --compression with five settings: off, fastest, auto (the default), better and max. RESTIC_COMPRESSION sets the same choice. Each step up spends more CPU to save bandwidth and space (restic tuning docs). The fastest and better settings are new. restic 0.19.0 added those extra zstd levels on 2026-06-09 (changelog); 0.14.0 originally shipped auto, max and off.

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, decide what a compromised backup client is allowed to destroy. With direct storage credentials, deletion resistance depends on the provider’s IAM and retention controls. S3 Object Lock and B2 Object Lock provide retention controls; check the selected mode and who can bypass it. Ordinary B2 version retention can help recover an accidental overwrite or hidden file, but it does not stop a compromised key with deleteFiles permission from deleting versions. Keep delete/prune authority on a separate trusted maintenance identity where the backend supports it.

If you self-host the protocol, rest-server has an --append-only mode. Kopia Repository Server keeps storage credentials off clients and supports READ, APPEND and FULL ACL modes. Inspect the exact semantics: Kopia grants users full access to their own snapshot manifests by default. “Append-only” does not mean perfect immutability. Test a restore too.

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. One community report describes a move from Kopia to restic after OneDrive over rclone proved unreliable.

Borg documents no object-storage backend in its quickstart or FAQ. This conclusion comes from the documented backend list rather than an explicit “no object storage” sentence. The FAQ points in the other direction. It recommends running the client where the source data is local and borg serve over SSH where repository storage is local, and it advises against NFS 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. The docs caution that some filesystems are too unstable 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

The restic and Kopia compression documents reviewed here do not advertise an equivalent to that last mode. 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 can write directly to cloud or filesystem storage without their own server, and both also offer optional repository servers. If your offsite target is a friend’s NAS, a rented VPS, or a Backblaze bucket where you cannot install arbitrary software, direct-backend support 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 changelog dates it 2026-07-19, the same release read in a different timezone. The newest 2.0 prerelease is 2.0.0b24, published 2026-09-02, while 1.4.5 remains stable (Borg releases API; 2.0.0b24 release). This comparison therefore bases its recommendation and commands on Borg 1.4.5.

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 show

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

deajan/backup-bench is the only reproducible-by-design suite we found, but it was 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. That is 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 because they measure different jobs. 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. Their transports, datasets and versions differ. Neither settles the speed question.

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.

Prove a restore before you choose

A repository check and a restore drill answer different questions. The check can show that repository structures and stored content are internally consistent. Only a restore into an isolated target lets you inspect the file you expected or start the application you meant to recover.

The uppercase labels (REPO, HOST, SOURCE_PATH, ARCHIVE and ROOT_ID) are placeholders. Replace them with values from your own repository. Each restore target is a new scratch directory, preventing the drill from overwriting a live tree.

In the restic command, --host and --path select which latest snapshot to restore; they do not restrict its restored contents. That row restores the selected snapshot into the scratch target. In the Borg row, use a path as stored inside the archive, relative to its root.

Full reads can take substantial time and can transfer billable data from a remote repository. Choose a schedule that fits the repository. Record whether the clean-target restore completed and whether a known file or restored application was usable. These commands are documented test paths. TechFuel did not run them against a backup repository for this comparison.

Five details that change the backup choice

One. The compression correction, with the version. restic 0.14.0, 2022-08-25, repository format v2, five modes today. “All three compress” misses the migration step. An old repository needs migrate upgrade_repo_v2 plus prune, and after migration it requires restic 0.14.0 or newer.

Two. The memory claims. Old write-ups can make restic’s RAM use sound like a universal barrier for a small VPS. The current restic docs give no per-terabyte formula. They say that limiting usable CPU cores can slightly reduce memory use, the backend can add a similar amount, and temporary space equals pack size multiplied by backend connections plus one. Default pack size is 16 MiB, tunable with --pack-size or $RESTIC_PACK_SIZE; larger packs mean fewer repository files and better upload performance (restic tuning docs). Borg’s guidance is also qualitative: allow enough RAM for the repository index and caches. The 111 MB / 75 MB / 176 MB peaks above belong to one 370 MB test and are not product specifications.

Three. Wrappers change the operator experience. Two r/selfhosted discussions about restic and Borg and restic and Kopia mention Backrest, autorestic, borgmatic and Vorta alongside the underlying tools. That small, self-selected sample cannot rank their popularity. It does show that a binary-only comparison can miss the interface people operate day to day.

Four. Verification depth. Kopia’s daily full maintenance runs snapshot verify, but the default verifies structure and referenced-content existence without downloading, decrypting and decompressing every file. Deep verification is explicit: --verify-files-percent=100 reads all file content, while a lower percentage samples it (Kopia consistency docs). On remote storage that deeper pass transfers data and may create provider-specific egress charges; default verification and deep content verification should not be treated as the same operation.

Five. Kopia documents AES-256 and ChaCha20, with a footnote explaining why a common marketing label is imprecise (Kopia features). It also scopes compression per policy: algorithm, minimum and maximum file size, and file extensions (Kopia compression docs). That is precise control for a repository holding both compressed media and text logs.

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

Bucket destination, command-line comfortable, mixed OS: restic. Its single-binary, one-flag operation has less surface to learn, and its Windows VSS handling is documented in more depth. Kopia remains a fair choice when a GUI and per-policy control matter more than the smaller CLI.

Bucket destination, non-technical users or desktops to cover: Kopia. KopiaUI is the only official GUI of the three. Per-policy compression also lets one repository apply different rules to a media laptop and a log server.

SSH destination you fully control: Borg 1.4.5. The stable release has the widest choice of compression algorithms, including obfuscate. Kopia instead has the finest compression scoping by policy, file size and extension. Pick Borg for its algorithm menu and SSH-native design. Whichever tool wins, prove the restore; the cited Duplicati discussion provides one example of why a backup command’s success is insufficient.

The 3-2-1 rule describes the larger strategy: three copies, two devices and one off-site copy. RAID is outside that count. Source snapshots and a 3-2-1 backup target remain separate jobs; Sanoid/Syncoid and Proxmox Backup Server cover those adjacent layers.

Related reading

• 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

• restic v0.14.0 release notes
• restic changelog
• restic repository preparation
• restic backup documentation
• Working with restic repositories and integrity checks
• restic restore documentation
• rest-server append-only mode
• Amazon S3 Object Lock
• Backblaze B2 lifecycle rules and retained file versions
• restic tuning parameters
• restic project
• restic latest release API
• Borg quickstart
• Borg installation
• Borg FAQ
• Borg command help
• Borg mount documentation
• Borg check documentation
• Borg extract documentation
• Borg releases API
• Borg 2.0.0b24 release
• Kopia repositories
• Kopia features
• Kopia compression
• Kopia installation
• Kopia consistency and verification
• Kopia restore reference
• Kopia Repository Server
• Kopia latest release API
• backup-bench README
• backup-bench repository
• ComputingForGeeks backup-tool comparison
• r/selfhosted: choosing restic or Borg
• r/selfhosted: restic and Kopia backup discussion