restic, Borg or Kopia: backup tools compared for business operations

Your backups run, but has the restore ever been tested? WZ-IT sets up backups, tests restores regularly and documents them as part of managed operations. Review your backup design with us

There is no shortage of comparisons between restic, Borg and Kopia, and almost all of them come from the homelab world. Different things matter there: how fast the first run completes, how much space deduplication saves, which tool has the nicer interface.

In business operations the emphasis shifts. A backup that runs daily is worthless as long as nobody has verified that a working system comes back out of it. And the question of which tool backs up 15 percent faster is secondary to who performs the restore when it counts.

This article assesses the three tools against verifiable criteria and then names the points where backup designs actually fail. All figures from the repositories, as of July 2026.

Table of contents

• The three tools at a glance
• What all three do the same
• Where they differ
• Version state as a decision factor
• restic
• Borg
• Kopia
• Scope: file backup is not system backup
• Which tool for which situation
• Where backup designs actually fail
• How we approach this at WZ-IT
• Further guides

The three tools at a glance

Figures from the public repositories, as of July 2026.

All three are unrestricted open source. None separates features into a proprietary portion, as has become common in other areas. For a tool standing between you and data loss, that is not a trivial point.

What all three do the same

The commonalities outweigh the differences, and comparisons rarely say so plainly:

• Encryption before transfer, with keys that stay with the operator
• Block-level deduplication, so identical content is stored once
• Versioned snapshots from which any earlier state can be restored
• Retention rules, for example seven daily, four weekly, twelve monthly
• Verification of stored data against silent corruption

Anyone operating one of the three properly does not get a worse outcome than with another. The choice governs effort and fit, not safety.

Where they differ

The most consequential difference in operation is the far end. Borg expects a running Borg on the target side, which brings speed and requires a server. restic and Kopia treat the target as dumb storage, which makes object storage immediately usable and shifts computation to the source.

A practical rule follows: if you want to back up to object storage without running another server, restic or Kopia get you there faster. If you run a backup server anyway, Borg's model is available to you.

Version state as a decision factor

A point absent from homelab comparisons but asked about in businesses: restic and Kopia are both formally pre-1.0.

That is not disqualifying. Both have been used in production for years, and restic has the widest adoption of the three at over 35,000 stars. But a pre-release version customarily reserves the right to change behaviour and formats, and for a backup tool that potentially concerns the readability of older snapshots.

Practical consequence regardless of the choice: updates to the backup tool belong tested like any other change, specifically with a restore from a snapshot created before the update.

restic

The most widely adopted of the three, under BSD-2-Clause, written in Go and distributable as a single executable. Addresses S3, Backblaze B2, Azure, Google Cloud Storage and SFTP directly, and connects to practically any other target through rclone.

Its strength is the breadth of targets and the simplicity of setup. The current version v0.19.1 dates from 5 July 2026.

Borg

The oldest of the three and the only one with a 1.x release, currently 1.4.5 from 18 July 2026, under BSD-3-Clause. Designed around a repository that is either local or reachable over SSH, with Borg on the far side.

That design brings speed advantages on large estates and requires a backup server. For object storage as a target, Borg is the most awkward of the three.

Kopia

The youngest of the three, under Apache-2.0, and the only one with a graphical application alongside the command line. It also addresses S3-compatible targets directly. Currently v0.23.1 from 16 June 2026.

The graphical interface is the clearest differentiator. For servers under automation it is irrelevant; for workstation backups performed by varying people it is not.

Scope: file backup is not system backup

A point where designs regularly come apart: these three tools back up files and directories inside a running system. They do not back up virtual machines as a whole.

Anyone running Proxmox needs a backup for machines and containers that understands the virtualisation. That is Proxmox Backup Server, which works at block level and tracks changes between runs. How it connects to object storage we covered separately.

In practice both layers run side by side: machine backup for full recovery, file backup for individual data sets, longer retention or systems outside the virtualisation.

Which tool for which situation

Where backup designs actually fail

In our experience none of the points above decides the outcome of a real incident. These four do:

The restore was never tested. The most common finding. Backups have run for years and nobody has ever restored. Whether the result is a working system only becomes clear when you need it, and by then it is too late for surprises.

There is only one location. Ransomware now explicitly targets reachable backups. A copy that can be deleted from the backed-up system is not a copy under attack.

The restore duration is unknown. Restoring three terabytes over a 100 Mbit line takes days. If the expectation is four hours, the design is wrongly dimensioned, regardless of the tool.

Databases are backed up as files. Copying a running database out of the file system produces an unusable state in the worst case. Databases need their own dump or a snapshot taken with knowledge of the application.

How we approach this at WZ-IT

We use all three depending on the environment and have no house favourite. The choice follows the storage location and who needs to be able to operate the backup.

What we do not negotiate is the restore test. It belongs in operations, not in intentions, and it is documented. For the same reason every design carries a stated restore duration, measured rather than estimated.

In virtualised environments we combine machine backup and file backup rather than making one layer do both. That costs a little more storage and saves hours when it counts.

Further guides

• Proxmox Backup Server 4.2 with S3 storage - machine backup into object storage
• Proxmox Backup Server - the layer beneath file backup
• Managed operations - backup, monitoring and restore under contract
• Proxmox maintenance - ongoing operations including backup verification

Do you know how long a full restore takes? We measure it rather than estimate it, and bring the backup and the expectation into line. Book a call

Sources

• restic on GitHub
• BorgBackup on GitHub
• Kopia on GitHub
• restic: documentation
• BorgBackup: documentation
• Kopia: documentation