restic vs Borg vs Kopia: which backup tool for a Linux server

Versions and status in October 2026

The current releases are restic 0.19.1 (July 2026), Borg 1.4.5 (July 2026) and Kopia 0.23.1 (June 2026). Borg 2.0 is in beta, at 2.0.0b25 (September 2026), and its README says: "DO NOT USE BORG2 FOR YOUR PRODUCTION BACKUPS!" Everything below about Borg means 1.4 unless it says otherwise. All three are open source and free; you pay only for storage.

Full guides: restic and BorgBackup; for a web UI with point-and-click restores, Duplicati.

Side by side

This page quotes no speed numbers, because speed depends on your files, CPU and storage. If it matters, back up a copy of your own data with each tool and time it.

Retention: the same flag gives different results

restic and Borg count periods that contain a backup. Kopia counts periods back from the newest snapshot. The difference shows when backups pause. A server backs up nightly at 02:30, is switched off from 3 to 9 October, and backs up again on 10 and 11 October. After the 11 October run, a keep-daily 7 rule on its own keeps:

In Kopia, the others survive only if another rule keeps them. Its default --keep-latest of 10 would keep all of them here, so set keep-latest to the number of recent snapshots you never want to lose. Preview any policy change first with restic forget --dry-run, borg prune --dry-run --list or kopia snapshot expire --all. More on choosing numbers in backup retention policies.

The same job in each tool

Each tool reads its repository location and credentials from environment variables or a connection file; the linked guides set those up. A nightly run with seven daily backups kept, in each tool:

# restic
restic backup /etc /var/www
restic forget --keep-daily 7 --prune

# Borg 1.4
borg create ::'{hostname}-{now}' /etc /var/www
borg prune --keep-daily 7
borg compact

# Kopia (the policy is set once and applied after each snapshot)
kopia policy set --global --keep-daily=7
kopia snapshot create /etc /var/www

Which one for your setup

One VPS backing up to S3-compatible storage. restic or Kopia; both write to the bucket directly with nothing else running. restic keeps every step in your own script (backup, then forget --prune, then check) and compresses by default. Kopia keeps the policy in the repository, applies it after each snapshot and runs maintenance itself, but leaves file compression off until you set it. Borg 1.4 would need a second server.

Many servers into one repository. Kopia. Its docs describe any number of machines writing at once with one maintenance owner, and its Repository Server lets clients log in with a username and password without holding the storage keys. restic also handles parallel backups, but every server then holds the repository password and a key that can delete, and prune holds up every backup while it runs. Borg's FAQ advises one repository per client.

A backup server that starts the backups over SSH. Borg first. Its docs include a pull-mode guide with three methods: mount the client with SSHFS, tunnel borg serve through socat, or forward an SSH agent. restic's docs show a close equivalent: the backup host runs rest-server and opens an SSH session to the server with a reverse tunnel (ssh -R), and restic on the server backs up through it, so the repository server is never exposed. Kopia's docs have no pull-mode guide. If push is fine, all three can keep the repository on a backup server: Borg with borg serve, restic with rest-server, Kopia with SFTP or its Repository Server.

Ransomware-resistant. The server being backed up must not be able to delete its own backups. Kopia does it inside the bucket: create the repository with --retention-mode COMPLIANCE --retention-period 30d in a bucket with Object Lock enabled, then run kopia maintenance set --extend-object-locks true. With restic, run rest-server with --append-only on another machine and run forget with --keep-within from a trusted one, as restic's docs advise. With Borg 1.4, give the server an --append-only key and prune and compact only from an admin key. See protecting backups from ransomware.

What none of them do

• Copy a live database consistently. They read files as they find them, and a database's files mid-write may not restore. Dump first with pg_dump, mysqldump, mongodump or SQLite's backup command, then back up the dump.
• Report a run that never happened. restic and Borg report through exit codes, and Kopia can send notifications after snapshots (kopia notification profile), but none can tell you about a run that never started because the server was down or the timer was off. Watch from outside: backup failure alerts.
• Prove a restore works. restic check, borg check --verify-data and kopia snapshot verify show the data is intact, not that your application comes back. Schedule test restores.
• Recover a lost password or key. Each repository is unreadable without it. Store it away from the server.
• Keep a second copy on their own. One repository is one copy. For 3-2-1, restic copy and kopia repository sync-to write a second repository; the Borg FAQ allows copying a repository with a tool like rsync or rclone while no backup runs, but warns never to use the copy and the original as two live repositories.

Frequently asked questions

Is restic better than Borg?

Neither wins everywhere. restic writes straight to S3-compatible storage and lets several servers back up to one repository at once. Borg 1.4 needs a server running Borg over SSH and allows one writer at a time, but has documented append-only and pull-mode setups.

Can Borg back up to S3?

Not Borg 1.4, the stable series. The Borg 2 beta adds s3: and b2: repository URLs, but its README says not to use Borg 2 for production backups. For a bucket today, use restic or Kopia.

Which of restic, Borg and Kopia compresses by default?

restic (zstd, auto) and Borg (lz4). Kopia compresses only metadata until a policy turns compression on, for example --compression=zstd.

Is Kopia stable enough for servers?

Its releases are numbered 0.x (0.23.1 in June 2026), as are restic's (0.19.1). Kopia's docs mark native Google Drive and rclone storage experimental; S3, SFTP and filesystem repositories carry no such label. Scheduled test restores tell you more than version numbers.

Can these tools back up a running database?

Not safely by copying its files. Dump the database first (pg_dump, mysqldump, mongodump) and back up the dump file.